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previous satellites with similar missions and determines the processor functions required 
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message system. A reliable processor design that implements these functions is devel- 
oped. The reliability of the proposed design is examined. Minimum software require- 
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I. PROBLEM DEFINITION 



A. PURPOSE 

The purpose of this study is to lay out the requirements of the on-board processor 
for the Petite Amateur Na \7 Satellite. Once the requirements are fully established, a 
design will be specified that meets the requirements. This design will include the division 
of labor between software and hardware. Finally, the hardware reliability will be exam- 
ined. 

B. THE PETITE AMATEUR NAVY SATELLITE 

The Petite Amateur Navy Satellite (PANSAT) is a small, simple, and inexpensive 
satellite currently being designed at the Naval Postgraduate School. PANSAT is in- 
tended to be a space-based communications e.xperiment that provides students with 
hands-on experience in satellite design and operations. It will accomplish three objec- 
tives. First, it will serve as an educational tool for NFS students, offering them experi- 
ence in satellite design and operations. Second, it will prove NPS capability in satellite 
design. Third, it is the first step toward the Space System Academic Group's ultimate 
goal of producing the ORION satellite. It is a simpler and less capable satellite than 
ORION. Therefore, it can be produced for a fraction of the cost of the final version of 
ORION. Simplicity and reduced cost will help minimize the risks inherent in a first de- 
sign. A tentative launch date has been set for July, 1991. [Ref 1: p. 1] 

1. Background 

The ORION project has been in progress for several years at NPS. The goal is 
to design and launch a small, general purpose satellite bus. While the ORION design is 
nearly complete, it has the disadvantage of being a complicated and expensive first at- 
tempt at satellite design. Before ORION can be fully funded, NPS must prove its capa- 
bility by designing and operating a simpler satellite. PANSAT is the vehicle intended to 
prove this capability. PANSAT will be less than half the size of ORION. In addition, 
although ORION will be attitude stabilized, PANSAT will have no attitude control. A 
successful launch and operation of PANSAT will provide the ORION project with the 
additional groundwork and data to serve as a baseline on which to build. 

2. Mission 

The primary mission of PANSAT is to conduct a space-based communications 
experiment which will provide students with experience in design and operation of such 
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a system. The desired implementation is a store and forward message system. This al- 
lows an authorized user to input a message while the satellite is overhead. At a later 
time, another authorized user can review the message subjects carried by the satellite and 
retrieve those of interest. Outdated or retrieved messages can be deleted. Telemetn.' or 
orbital data can also be collected on-board and stored as messages. 

In addition, several secondarv’ missions are being considered. These would in- 
clude carrying small sensors for other experiments if volumes and weights permit. Var- 
ious programs could be loaded into the satellite processor, allowing students experience 
in writing software kernels for satellite control. These programs could also be modified 
to monitor memory errors over time, allowing students to evaluate effects on memorv' 
circuits from exposure to increased radiation and harsh environment. If sensors are in- 
cluded, power usage by memor\’ and processor components could be measured over time 
to further evaluate exposure effects on semiconductor products. The more inherent 
flexibility available on-board to reconfigure the processor, the greater the possibility that 
additional experiments can be programmed and implemented. 

Underlying these experiments is the primary mission of educating students in 
space design and operations. This goal will be achieved by involving students at all levels 
of design and operations. Furthermore, increased processor flexibility will maximize op- 
portunities for student involvement by permitting additional experiments. 

3. PANSAT Design 

The following are working design constraints that impact on the processor sys- 
tem design. 

a. Orbit 

The first PANSAT is planned for launch from the space shuttle without any 
extra booster. This constrains the satellite to a low earth orbit of approximately 150 to 
200 nautical miles. Actual orbit will depend on shuttle parameters of the particular 
mission that launches the PANSAT. Typical orbits have a 90 minute period at an in- 
clination of 28.5 degrees [Ref 2: p. 2] The orbit will also determine communication op- 
portunities with the satellite. These orbits will provide only one or two ten-minute 
communications windows per day for any particular ground station. 

b. Size 

The Get Away Special canister size limits the physical size of the satellite. 
If a regular size canister is used, this limits satellite size to approximately 19 inches in 
length by 19 inches in diameter. Working within these limits, a octagonal cross section 
design is planned to maximize solar collector area. The planned overall dimensions of 
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the PANSAT are shown in Figure 1 on page 4. The volume within the satellite allocated 
for the processor is shown in Figure 2 on page 5. 

c. Stabilization 

The PANSAT will not be stabilized and will not have any station keeping 
ability. This eases requirements on processor capability because the processor will not 
be required to monitor any attitude sensors or perform stabilization calculations. One 
drawback is the requirement for multiple antennas to enable uninterrupted communi- 
cation with the satellite as it tumbles overhead. The restriction to omnidirectional an- 
tennas will negatively impact the communications power budget. Lack of attitude 
control also implies that thermal control will have to be passive. 

d. Communication 

Communication with the PANSAT will be in the 144-146 .MHz band. The 
type of communication protocol remains to be specified. Options for the physical 
transmission method are using voice band transmitters and receivers with modulators 
and demodulators performing the required analog to digital conversion or using a direct 
digital method. The protocol for controlling transmission is yet to be determined. The 
data rate will be limited to not more than 9600 bits per second and will be in a serial 
format. The reason for the 9600 bps limitation is two fold. First, a low data rate will 
conserve power on the satellite. Second, it will allow a small computer to be used as the 
basis for a ground station. 

e. Power 

The satellite will be powered by an array of solar cells mounted on the e.x- 
terior. These will charge a bank of 28 two volt, five amp-hour sealed lead-acid batteries. 
This will provide a 28 volt, redundant bus. The power system has not been designed, 
but initial estimates indicate that three watts of continuous power may be used. A peak 
power usage of 50 watts is envisioned; this usage will be sustained only during the time 
the satellite is communicating with a ground station. During the remaining portion of 
the orbit the satellite will be quiescent, providing an opportunity to recharge the bat- 
teries. [Ref 1: p. 2] 

/. Durability 

The satellite will be subjected to high vibration during launch and orbital 
injection. The overall root mean squared vibration level is 12.9 g's for 40 seconds [Ref 
2: p. 57]. The processor (as well as the entire satellite) must be able to withstand these 
stresses without failure. 
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Figure I. PANS AT Overall Dimensions 
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Figure 2. PANSAT Processor Envelope 
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g. Lifetime 

The processor must be able to function properly during the satellite's design 
lifetime of one and one half years. The design should be such that system failure can 
be avoided. If a fault occurs, the design should minimize the impact on the mission by 
redundancy (appropriate to the relative simplicity of the satellite) or by allowing the 
processor to work around the fault. 

C. PANSAT FUNCTIONS 

The following functions are to be performed by the satellite. 

• Interrogation response; When interrogated by a specified command tone (or 
combination of tones), the satellite will respond (in a manner to be determined). 

• Orbital store and forward message service: The satellite will be capable of receiving 
messages via a communications link, storing the messages, and transmitting them 
upon request. 

• Flashing strobe lights on command: When a specified command is received, the 
satellite will flash externally mounted strobe lights. 

The specific format and limitations of these functions are to be determined in the 
course of this design study. In addition to the functions listed above, the processor must 
manage housekeeping functions in support of the mission functions. These support 
functions include, but are not limited to: 

• Control of communications between the satellite and ground stations, including 
positive control over the on-board transmitter(s). 

• Management of the mailman message buffer. 

• Power management and battery charging, including sleep and wake commands. 

• Generation and formatting of status messages. 

• Reception, decoding, and execution of commands from the ground control station. 

• Fault detection and recovery. 

• Ability to update or change programming. 

• Storing telemetry data in an on-board buffer (perhaps the store and forvt^ard buffer) 
for later relay to ground station. 

D. ENVIRONMENT CONSTRAINTS 

The satellite will operate in low earth orbit, imposing certain constraints on design. 
First, the atmosphere will be close to vacuum. Temperature w’ill range from -160°C to 
+ 100°C (Ref 2: p. 65]. No active cooling is envisioned for the satellite. Operating out- 
side the protection of the atmosphere will expose the satellite to solar and Van Allen 
radiation. Second, power will be limited by what can be provided by the solar cells. 



6 



Third, the orbit will limit communication with the satellite from any particular ground 
station to approximately 10 minutes each pass. Finally, once launched, the satellite will 
be inaccessible for repairs. 

E. DESIGN CONSTRAINTS 

The small size of the satellite will impose additional constraints on the processor 
design. The processor must have a small volume and weight. The weight constraint is 
not anticipated as a problem due to the small size and weight of currently available 
processors and peripherals. The available volume and footprint for the processor as- 
sembly is shown in Figure 2 on page 5. The system must be able to withstand the 
stresses of launch and orbital insertion. 

F. DESIGN ENHANCEMENTS 

The following items, while not design requirements, are preferred enhancements. 
They should be achieved if possible within space, power, weight, and cost considerations. 

1. Commonality 

The processor should be similar to one commonly available, preferably one in 
current use at NTS. This will simplify program development and allow increased edu- 
cational benefits. Program development is simplified by the larger number of software 
packages (specifically compilers and assemblers) available for a common processor. It 
is very desirable that the processor chosen have available high level language compilers 
to allow programming the processor in C or an equivalent language. The educational 
benefit is enhanced by allowing students to develop a program on a ground-based com- 
puter. Once debugged and verified it can be uploaded and tested on an actual satellite. 

2. Upwardly compatible 

The processor should have enough capability to expand easily to meet the ad- 
ditional computing requirements of ORION. These will include the capability to su- 
pervise the attitude control of the enhanced version. The processor will also have to 
manage communications with an on-board experiment, either by formatting and passing 
messages, or by exerting direct control over the experiment. ORION may carry a system 
to relay video images to a ground station. This implies a higher data rate on the ORION 
communication link than on the PANSAT communication link. A solid state bubble 
memory recorder is a candidate processor that will require interfacing with the processor. 
The PAN’SAT processor should have a growth margin to meet these future needs of 
ORION. In addition, if a single processor design is used it should be easily upgradable 
to a multiple processor configuration for these future requirements. 
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3. Real time clock 

A real time clock accessible through the processor is a possible enhancement. 
This would allow processor events to be scheduled for a specific time. 

G. RESEARCH QUESTIONS 

The research questions for this study may be identified as: 

• What computing power is required? 

• What processor(s) will meet this requirement? 

Should the approach be a microcontroller giving a potential single-chip design, 
or would a microprocessor design be more appropriate (with the larger chipset and 
footprint implied)? 

• What will be the layout of the system? 

Single processor versus multiprocessor. If multiple processors are used, should 
the system be tightly coupled or loosely coupled. 

• What is the proper division of tasks between software and hardware? 

• How will the computer system interface to; 

1. Power system, including batteries and solar cells? 

2. Communications system. 

3. Strobe lights. 

4. Any other on-board sensors. 

• What size of RAM and ROM is required. 

• What amount of radiation hardening is required? 

• What additional hardware (especially RAM) is required to support the store and 
forward function. Does this have a lower reliability standard? 

• What amount (if any) of security must be provided to prevent unauthorized control 
of the satellite? 

• How will communications with the satellite be handled? Will all communications 
go through the processor, or will there be a dedicated telemetry and command link? 
Will a custom communications protocol be used, or will a standard method be 
adopted? 

Specific software development will not be addressed beyond what is required to en- 
sure that the required functions will in fact be programmable (with a given margin for 
growth) within the hardware that is developed. 

H. CANDIDATE PROCESSORS 

The processor upon which the system is based should be commercially available in 
a low power, radiation hardened version. The following processors are candidates for 
consideration: 
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• S085 or equivalent 8 bit microprocessor. 

• 8086 or equivalent 16 bit microprocessor. 

• Z80, Z280 or NSC 800 8 bit microprocessor. 

• MC68000 16 bit microprocessor. 

• MC68HC1 1 microcontroller. 

• 8096 microcontroller. 

I. COMMUNICATIONS PROTOCOLS 

The protocol used for communicating between the satellite and a ground station will 
impact on processor design. The first question is what protocol to use. Either a stand- 
ard protocol, such as X.25, or a custom-designed protocol may be implemented. If a 
custom protocol is required, the error detection methods must be specified. If a standard 
communications protocol is to be used, what amount of computing must the software 
do and what amount will be done in specialized hardware? When referring to the seven 
layer ISO model for computer communication (see Table 1), which layers are handled 
in software and which in hardware? The physical layer, which includes the communi- 
cations equipment, is implemented in hardware. The second and third layers may be 
implemented in either software or hardware. Levels four and above are typically software 
based, and may not all be needed. Elimination of higher levels will simplify software 
requirements, and therefore hardware requirements, on the satellite. 



Table 1. ISO SEVEN LAYER MODEL 



Highest level 


7. 


Application layer 




6. 


Presentation layer 




5. 


Session layer 




4. 


Transport layer 




3. 


Network layer 




2. 


Link layer 


Lowest level 


1. 


Physical layer 



J. DESIGN SCOPE 

The conceptual design breakdown of PANSAT is shown in Figure 3 on page 10. 
The processor is a central portion of the design as it interfaces with all other systems. 
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This design concentrates on the block labeled hardware design. Since most other areas 
arc still conceptual, assumptions are made and dclended where necessary. 




Figure 3. PANSAT conceptual design 
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II. SYSTEM REQUIREMENTS ANALYSIS 



A. PREVIOUS DESIGNS 

Many amateur satellites have been constructed over the years. These designs are 
an important starting place because the capability is similar to that desired for PANSAT. 
Three designs are of special interest. These are the UoSAT-2, UoSAT-D, and FO-12 
satellites. Pertinent design features of the processors on these satellites are summarized 
in Table 2. 



Table 2. SATELLITE PROCESSOR SUMMARY 



Satellite 


UoSAT-2 (Oscar-11) 


FO-12 (Oscar-12) 


UoSAT-D 


Purpose 


digital comm exper- 
iment 


orbital mailman 


orbital mailman 


Processor 


NSC-800 (Z-SO) 


NSC-800 (Z-80) 


80C186 


3 cards 6"x9"xl" 


10 cards 6.3"x5.91" 
329 ICs 




0.9 MHz 


1.7 MHz 


8 MHz 


Comms 


MSG-2 


AX.25 


AX.25 


UARTs 


discrete HDLC con- 
troller 3 cards 
6.85"x8.74" 144 ICs 






4 uplink 1 downlink 




1200 bps 


1200 bps 


9600 bps 


Power 


1 watt 


3.5 watts 


(not given) 


Memory 


126 kbyte static RAM 


1 Mbvte dvnamic 
R.WI 


4 Mbytes 


512 bytes PROM (re- 
dundant), 16 kbytes 
of RAM have one bit 
EDAC 


(No SRAM or 
PROM), 32 kbytes 
kernel, stack, and 
static, 4 X 256 kbyte 
cards bank switched, 
1 bit EDAC 




Attitude 

control 


gravity boom, active 
magnets 


spin, passive magnets, 
lossy dampers 


gravity boom, active 
magnets 
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1. UoSAT-2 



THe UoSAT-2 was designed as a digital communications experiment to prove 
technology to be used in follow-on satellites. It utilized a XSC-800 processor (similar to 
a Z-80) running at 0.9 MHz. The communications link operated at 1200 bits per second 
utilizing a custom message protocol. This custom protocol, MSG2, was used due to lack 
(in 1985-86) of a low power CMOS HDLC controller chip or room for a discrete HDLC 
implementation. This protocol is byte oriented. The MSG2 frame format is shown in 
Figure 4. Byte stuffing is used to ensure the frame marker, [10h][03h]. does not occur 
within the frame. When [lOh] is to be transmitted, it is changed to [10h][10h], then re- 
converted after reception. The kernel implementing MSG2 was written in Z-80 assem- 
bler code and occupies 2.5 kilobytes of error detection and correction protected (EDAC) 
FLAM. Ground stations must have a custom software package to communicate with this 
satellite. [Ref 3] 

[10h][03h] <command> <commandnot> <datalength> (data) <<CRC>> 

< > indicates byte data 

< < > > indicates 16 bit data 

( ) indicates variable length, defined by data length byte 



Figure 4. MSG2 protocol frame format 



There are several ideas used in the UoSAT-2 that may be applicable to the 
PANSAT design. These are: 

• Successful use of commercial grade RAM chips in a low earth orbit environment. 

• Error detection on vital RA.M (non-vital RAM does not have error detection). 

• Whole orbit telemetr>’ monitoring using message RAM to store data for downlink 
while satellite is overhead. 

2. UoSAT-D 

The L’oSAT-D satellite is a packet communications experiment that builds on 
UoSAT-2. UoSAT-D implements the AX. 25 packet radio protocol operating at 9600 
bits per second in full duplex mode. It utilizes a 80C186 processor operating at 8 MFlz. 
This processor has sufficient processing capacity to handle all the satellite's internal 
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housekeeping concurrent with packet radio operation. UoSAT has developed software 
for the ground stations that is available if the AX. 25 protocol is adopted. [Ref 4] 

3. FO-12 

The FO-12 satellite is a store and forward digital mailbox. It implements the 
AX. 25 protocol with four uplink channels and one downlink channel, all operating at 
1200 bits per second. The AX. 25 protocol was implemented in discrete CMOS logic. No 
ROM was used in FO-12. Initial program load was accomplished via hard-wired logic. 
[Ref 5] 

B. RADIATION EFFECTS ON CMOS DEVICES 

The processor for PANSAT will be constructed mostly from complementary metal 
oxide semiconductor (CMOS) integrated circuits. The advantage of CMOS is the ex- 
tremely low power consumption exhibited by these devices. Low power consumption 
also implies reduced generation of excess heat, an important consideration in a satellite 
with only passive thermal control. In addition, power consumption can be controlled 
by regulating the frequency of operation. (Lower speeds require lower power.) However, 
CMOS circuits can be adversely affected by radiation in the space environment. 

The interaction of particles and energies can actually be broken down into two main 
mechanisms which dominate the efl'ect of radiation in materials in which we are 
concerned: 1. Displacement of atoms from their lattice structure (displacement 
damage). 2. Generation of electron-hole pairs (ionization). Both elTects can cause 
temporarx' (transient) or permanent damage to semiconductors. [Ref 6; p. 2-5[ 

Radiation hardened circuits are designed to minimize the long term eO'ects of radiation. 
However, this hardening makes the circuits much more expensive than equivalent in- 
dustrial quality devices. Memorx' devices are especially affected by increased cost. Since 
radiation damage occurs over time, it may be possible to use a mixture of industrial 
quality and radiation hardened components to meet the lifetime requirement for 
PANSAT. 

A second type of disturbance occurs specifically in memory devices. A high speed 
particle may traverse through the semiconductor leaving an ionized path. This ionization 
may be sufficient to cause a static inverter to change state, or a dynamic storage element 
to lose charge. In the worst case, the particle will leave an ionization path through to 
the substrate and cause latch-up. Either process will cause corruption of at least one bit 
of memory. Latch-up will result in increased current draw and will require removing 
power from the circuit to reset the condition. Temporarx' loss of a bit, xvhile corrupting 
the stored value, can be remedied by revx'riting the affected word. When the disturbance 
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is temporary and can be remedied by rewriting the affected value, it is termed a single 
event upset (SEU). Like permanent damage effects, SEUs can be reduced by using ra- 
diation hardened memory devices. VV'hile the physical process that causes these events 
is known, 

...prediction and simulation of the SEU rate for a given satellite in a given orbit are 
veiy inaccurate. The SEU rate depends on: memory device manufacturing technique, 
device geometry, shielding, satellite orbit, satellite attitude, solar activity, (and) 
geomagnetic activity. [Ref 3] 

The UoSAT-2 experiment experienced 21 SEUs in a period of 185 days in 144 kilobits 
of industrial quality memorv’. The equivalent shielding of the memor>’ was not specified. 
Since the orbit of PANSAT will be lower than UoSAT-2, SEU rates will probably be 
lower, reducing the requirement for error detection and correction. [Ref 3] 

C. INTEGRATED CIRCUIT SCREENING LEVELS 

Device screening and qualification varies depending on the manufacturer. Specific 
quality requirements for government applications are established in MIL-STD-8S3 and 
MIL-M-38510. These standards establish quality requirements for militaiy’ Class B, 
Class S, and radiation hardened devices. Class B qualification is required for devices used 
in typical militaiy applications. Class B screening includes a 100% burn-in test at 
+ 125°C to weed out potentially defective items. Class S qualification places the most 
stringent requirements on the devices. Testing begins with wafer lot acceptance. All 
devices are subjected to a bond pull test where each connecting wire from the die to the 
package is tested to ensure that it will not detach. These devices are individually serial- 
ized. The circuit is burned-in at + 125°C for 240 hours, then reverse biased at + ISO^C 
for 72 hours. Other statistical and electrical checks are performed, ending with two sep- 
arate x-ray views of the device. Due to the stringent test requirements of Class S quali- 
fication, few devices survive screening. This makes the cost of Class S devices 
considerably higher than devices tested to lower standards. In addition, few manufac- 
turers perform Class S screening; this screening is typically on a custom order basis. 
Manufacturers often provide Class B or Class S 'look alikes.' These devices follow a flow 
that is similar to MIL-STD-8S3 but may be obtained at a lower cost. The basic screening 
levels are summarized in Table 3 on page 15. [Ref 6: pp. 13-8 to 14-21} 

In following sections, high reliability devices will indicate those that meet the JAN 
Class B screening. Radiation hardened will indicate devices that are certified with 
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MIL-STD-8S3 Group E radiation hardness assurance tests in addition to the Class B 
screening. 



Table 3. DEVICE SCREENING LEVELS 



Level 


Temperature 
range (®C) 


Screening includes; 


Represen- 
tative cost 
(8086) 


commercial 


0 to +70 


statistical 


S22 


industrial 


-40 to + S5 


statistical, may require burn-in 


S38 


military (High reli- 
abilitv, JAN class 
B) 


-55 to +125 


100® 0 testing, bum-in 160 
hours at + 125°C 


S261 


radiation hardened 




Samples from each wafer sub- 
jected to radiation tests 


S800 


military (space 
qualified, JAN 
class S) 


-55 to + 125 


100®/o serialization and ex- 
haustive testing, burn-in 240 
hours at + 125°, x-ray after 
burn-in. 


greater 
than S2000 
for Class S 
look-alike 



D. DESIGN INTERFACES 

The PANSAT processor will interface with all satellite systems. The major subsys- 
tems are: 

• Communications system 

• Power supply and battery charging system 

• Experiments 

• Structural system 

In addition, the processor hardware will interact with the processor software to accom- 
plish assigned tasks. At present, only the PANSAT structural system has been designed. 
Since the other systems are not yet designed, this design will make educated assumptions 
about these other systems and required interfaces. These assumptions may prove incor- 
rect in the long term, but they provide a starting place for the processor design. 

E. PROCESSING POWER 

The processing power required in PANSAT is dependent upon the tasks assigned to 
the processor. These tasks can be divided into four categories: 
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• communications 



• housekeeping 

• telemetry 

• command execution 

The communication task will consume most of the processor capability so it was inves- 
tigated first. 

1. Communications 

a. Number of communication links 

Previous satellites designed to accomplish a mission similar to PANSAT 
have used at least two communication links. One link is a specialized channel to transmit 
commands to the satellite and receive telemetry data from the satellite. The second 
channel (in some cases several channels) implements the digital store and forward mes- 
sage system. Many users have access to the store and forward channel operating in a 
known format. Only the ground control stations know the correct format and frequen- 
cies for the command channel. The digital message channel can also be used by the 
controlling station to upload revised programming. Use of more than one channel gives 
the satellite redundancy. If the command channel fails, the message channel can be used 
to send commands to the satellite. Telemetry can be sent either over the dedicated 
channel, or can be collected by the processor, formatted, then sent over the digital 
communication channel. The disadvantage of this approach is that two separate 
transceivers must be located in the satellite. The size of PANSAT precludes using two 
transceivers. Restriction to a single communications link requires this link to accomplish 
all functions. 

Use of a single communications link makes the hardware design of the 
processor simpler. The tradeoff will be in the software which must become more complex 
to handle the following tasks over the single channel: 

• Command uplink, including satellite reprogramming. 

• Telemetry downlink. 

• Store and forward message system. 

• Hardware reset to restart system on program malfunction. 

The link must then be designed to embed the commands in the store and forward mes- 
sage format. Telemetry downlink will be placed into the message buffer and received as 
a forwarded message. Since a single link will be used which is accessible to amateur 
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radio operators, a security system is required in software to prevent an unauthorized user 
from reprogramming the satellite or inadvertently sending the reset sequence. 

This assumption of a single link is the most restrictive case. When the 
communications system is designed, it may prove possible to multiplex the digital link 
and a separate command link. If this is possible, this design will still be valid, with the 
separate link adding redundancy. 

b. Communications protocol 

The options for a communication protocol are to design a custom protocol 
or to use a standard protocol. The advantages of a custom protocol are that the capa- 
bilities of the specific satellite can be maximized. However, the disadvantages of using 
an unproven protocol, which include requiring a custom software implementation for 
both ground stations and the satellite, outweigh any possible benefit. Additionally, if a 
custom protocol is used, this will limit satellite accessibility to amateur radio operators. 

AX. 25 and MSG2 are the two probable choices for a standard protocol. 
MSG2 was illustrated previously in Figure 4 on page 12. AX. 25 is an extension of the 
standard X.25 data link control protocol. AX. 25 extends the address field to allow en- 
coding of amateur radio operator callsigns. Callsigns of up to six letters (one letter per 
byte, with an additional byte for secondary station identifier) are included for both 
sender and receiver. Up to eight repeater stations may be used, extending the address 
field to 512 bytes. The X.25 and AX. 25 formats are shown in Figure 5 on page 18. 
AX. 25 is a bit oriented protocol. The flag '01 1 1 1 1 10' is used to signal the beginning and 
end of a frame. The flag is prevented from occurring within the frame by inserting a '0' 
after any sequence of '11111.' This process, called bit stuffing, is compensated by the 
receiving station removing any '0' after a sequence of '11111.' [Ref 7: pp. 1-9] 

The differences between MSG2 and AX. 25 are summarized in Table 4 on 
page 19. Significant differences are the type of automatic repeat request (ARQ), infor- 
mation frame length, and orientation (bit versus byte oriented). The ARQ and frame 
length differences combine to determine maximum possible throughput. Processing 
power required is affected by whether the format is bit or byte oriented. 

To compare maximum theoretical throughput, the distance to the satellite 
must be determined. Assuming the satellite is orbiting 370 kilometers above the earth 
(H), using 6378 kilometers as an average earth radius (Re), and presuming the satellite 
elevation (E) must be above ten degrees for successful communication, the slant range 
to the satellite (d) is given by; [Ref 8: p. 45] 
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Table 4. COMPARISON OF MSG2 AND AX.25 



Protocol 


MSG2 


AX.25 


Orientation 


byte serial 


bit serial 


ARQ 


selective repeat 


go back N 


1 frame length 


up to 64 bytes 


up to 256 bytes (") 


Overhead 


7 bytes 


20 to 76 bytes 


* Some implementations may have a lower limit 



/ = [Re + Hf + Re^ - 2Re{Re + H)x sin[£+ sin"’( cos £)] (1) 

This gives a value of 1359 km for the maximum slant range. The minimum slant range 
will occur if the satellite is directly overhead at 370 km. Most communication will be 
done at a value between these two extremes. Since the satellite will rarely pass directly 
overhead, a nominal communication range of 1000 km will be assumed to compare 
throughput for the AX.25 and MSG2 formats. 

AX.25 uses go back N format, where N is eight. The throughput, p, for this 
format is given by; [Ref 9: p. 222.] 



P = 



1 -P 



1 + 



2Tp 

Tf 



P 



• P is the frame error probability: P = 1 — (1 — Pb)’'’’’ 

• Pb is the probability a single bit is in error. 

• Nb is the number of bits in a frame. 

• Tf is the time required for transmission of a frame. 

• Tp is the propagation and processing delay. 



( 2 ) 



MSG2 is a selective repeat format. The throughput for selective repeat is given by: [Ref 
9; p. 233] 



p=\-P 



(3) 



where P is given above. 
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A minimal AX. 25 frame will have 20 bytes of overhead. Assuming a ten 
percent overhead, this give an 1 frame size of 200 bytes, or 1600 bits. This overhead is 
similar to a 71 byte .MSG2 frame, which has 7 bytes of overhead. The throughputs for 
these protocols are compared in Figure 6 on page 21 using these assumptions. As bit 
error rate increases, throughput drops more rapidly for AX. 25 than for MSG2. Most of 
this difference comes not from protocol differences, but from the frame size effect on 
frame error probability. The frame error probability for AX. 25 could be reduced by de- 
creasing frame size. This would increase the fraction of overhead since the 20 byte 
overhead cannot be avoided. In a frame addressed through repeaters, overhead could 
increase to as much as 76 bytes. As long as single bit error probability remains below 
3 X 10"^ , throughput for AX. 25 is acceptable. This requirement to maintain low bit er- 
ror rate must be included in the design of the communication package for PANSAT. 

MSG2 is a byte oriented protocol. The processor does not require any ad- 
ditional hardware or special algorithms to implement the protocol. All that is necessary 
is to examine the byte stream for the byte [lOh]. This can be done by a simple compar- 
ison. In contrast, AX. 25 is a bit oriented protocol. The flag 'OllIlllO' can occur any- 
where in the bit stream, not just as a byte. This means that the entire bit sequence must 
be examined to detect any sequence of T 1 1 1 1' which must then be stuffed to prevent the 
flag from occurring within the frame. This requires either a dedicated data link control 
(DLC) protocol hardware device or complicated software algorithms. 

Although AX. 25 has a lower throughput than MSG2 and will be more 
complicated to implement, this is the protocol that will be implemented on PANSAT. 
This protocol is the current standard used for communication with amateur satellites. 
If this protocol is used, ground station testing can be conducted with amateur satellites 
presently in orbit. In addition, once PANSAT is in operation, other amateur ground 
stations will be able to access PANSAT's store and forward message system. 

The processor must be able to perform the bit stream formatting required 
in AX. 25. The communication link must be designed to maintain a bit error rate that 
does not adversely affect traffic throughput. 

c. Implementation of AX.2S communications protocol 

The communications protocol can be implemented either in software or by 
dedicated hardware support. A software implementation of AX. 25 will not be consid- 
ered. Although it is theoretically possible to implement, the task of examining the 
bitstream bit by bit and computing the CRC checksum for both an incoming and 
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Fractional throughput 



Percent of ideal throughput versus bit error probability 




Single bit error probability 
Figure 6. Throughput comparison of AX.25 and MSG2 



21 



outgoing channel at 9600 bps will severely task the software designer. Software 
implementation will only be considered if a hardware solution proves unfeasible. 

If a hardware implementation is used, the designer typically has three dif- 
ferent methods of controlling the hardware protocol chip. These are; 

• polled 

• interrupt driven 

• direct memorv’ access 

In a polled system, the processor must regularly interrogate the protocol chip to deter- 
mine if the chip is ready for input or output. In an interrupt configuration, the chip will 
interrupt the processor when it requires data transfer. In a direct memory access system, 
the processor stores the data parameters in the DMA controller and then initializes the 
chip. The data transfer then takes place with no further intervention from the processor. 
The DMA processor will then inform the processor when the transfer is complete. 

The polled system is the easiest to implement and requires little additional 
circuitry to perform. The disadvantage is that additional software complexity is required 
to allow the processor to accomplish other tasks while waiting to transfer data to the 
protocol chip. The DMA arrangement allows higher transfer rates as the pro< essor is 
not involved in transfers. The DMA controller 'steals' cycles from the processor to 
transfer data without requiring processor intervention other than to temporarily relin- 
quish the system bus. However, the DMA controller implies additional circuitry not 
required by the other implementations. In addition, the DMA controller is not available 
in a radiation hardened version. 

PANSAT requires an interrupt controller for several functions detailed in 
following sections. Therefore using an interrupt structure to service the hardware pro- 
tocol chip will not add to circuit complexity. Table 5 on page 23 shows a possible in- 
terrupt service routine used to provide data from a 8086 processor to a 8273 HDLC 
protocol controller. Assuming the processor operates at 5 MHz (with no wait states) 
then 163 clock cycles equates to 32.6 microseconds. At 9600 bits per second, the 
processor needs to process 1200 bytes per second, or one byte every 833.3 microseconds. 
In full duplex mode, there is one incoming byte and one outgoing byte every 833.3 
microseconds, each taking 32.6 microseconds. The fraction of available processor time 
used for HDLC control is 0.078. Thus using the processor to operate the 
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communications link on a byte by byte interrupt basis only requires about 8 percent of 
available processor time. 



Table 5. 8086 INTERRUPT ROUTINE TO SERVICE 8273 



Instruction 


Clock 

cycles 


Comment 


complete current instruction 


10 


(assumed average, not included in 
total) 


Interrupt processing 


61 


push CS, IP, FLAGS, get inter- 
rupt vector, and branch to service 
routine 


PUSH AX 


11 


save register 


PUSH BX 


11 




MOVE AL.[S1] 


8 + EA= 14 


get next byte 


OUT =HDLCOUT.AL 


10 


output to 8273 


INC SI 


2 


point to next item 


.MOVE ^RST1NT.AL 


4 




OUT j;INTPROC.AL 


10 


reset interrupt controller 


POP BX 


8 


restore registers 


POP AX 


8 




IRET 


24 




Total: 


163 





d. Higher layer protocols. 

Although AX. 25 has been selected for use, this is only the second layer 
protocol. This will transmit error free packets between the satellite and a groundstation. 
Higher level interfaces are required to reassemble these packets into complete messages. 
These higher level protocols must also determine what action to take with the message. 
These actions may include: 

• add message to the buffer, 

• retrieve message from the buffer, 

• list buffer messages, 

• issue satellite command or load a program, and 

• transmit telemetry data. 
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These commands are a function of the software, not the hardware implementation, and 
will not be considered further. (Higher layer software for the satellite and ground 
stations may be available from AM SAT.) 
e. Transmitter control 

A major concern for getting the PANSAT design approved for launch is 
demonstrating positive control over the transmitter. If the satellite has a malfunction, 
there must still exist means to secure the transmitter from the groundstation. Legally, 
telecommand capability is necessary: 

...to turn off a malfunctioning transmitter that might conceivably cause harmful in- 
terference to important radio services worldwide. [Ref 10 : p. 12-2] 

The processor can be configured to provide positive control over the transmitter. How- 
ever, if a failure occurs and the processor is no longer operating, this control will not be 
sufficient. A method must exist to secure the transmitter that does not presume the 
processor or HDLC hardware is operating. This method will be a function of the com- 
munication package. A unique sequence that would not normally be encountered could 
be assigned as a reset sequence. A sequence detector could be included in the transceiver 
to detect this sequence and secure the transmitter independently of the processor. This 
sequence must consider that transmitters may continuously sc nd flags while idle and that 
a sequence of 15 T 's is used as a frame abort sequence. Responsibility for further de- 
velopment of the processor failed transmitter control will be left to the communication 
package designer. A method to secure the transmitter on failure of the receiver will be 
discussed in a following section. 

2, Telemetry and commands 

The processor will be responsible for receiving commands over the digital link 
and executing these commands. In addition, the processor will monitor on-board sen- 
sors, collecting and formatting telemetry messages. Command execution is mostly a 
function of the software. The software must be designed to recognize that an incoming 
packet is a command to the satellite instead of a store and forward message. The soft- 
ware must implement security to ensure that only authorized stations can command 
satellite functions. The hardware interface will be a parallel output port that can com- 
mand relay drivers. Depending on the number of actuators to be driven, a multiplexer 
may also be required. 

Telemetry data will be gathered through an analog multiplexer and analog to 
digital converter. Some telemetr}' data concerning the communications package or the 
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embarked experiment may be sampled in a digital format. Again, it will be a function 
of the software to perform data collection and to format the data into packets for 
transmission. The number of input channels for telemetry and output channels for 
command actuation is yet to be determined. 

Processing power required for telemetrj' gathering is minimal. The processor 
needs only to select a multiplexer address, start analog to digital conversion, and read 
the results when the conversion is complete. Even if 64 channels of data (a large number 
for such a small satellite) are required to be sampled every five seconds, actual processor 
cycles required would be a small fraction of available cycles. Command execution is 
even easier. All that will be necessaiy^ is to output a bit or word to a parallel port to 
actuate a relay driver. (Xo capability for analog output is envisioned.) 

3. Housekeeping 

At present, the only housekeeping functions anticipated are control and moni- 
toring of the batteiy charging system. The power system for the satellite has not been 
designed at present beyond specifying redundant 28 volt battery banks. Each bank may 
require means to independently connect or disconnect the bank from the charging sys- 
tem or from the power distribution bus. This implies at least four actuation channels to 
drive relays. Monitoring the power system will require several telemetiw inputs. These 
will probably include; 

• voltage on each batteiy bank 

• charging current 

• power supply current draw 

• regulated bus voltage 

Actual monitoring and control will be determined when the power system design is fi- 
nalized. 

F. MEMORY 

The memoiy' system can be divided into three components. These are the fixed 
storage (PROM) that holds the operating system kernel, vital RAM that holds system 
vital data, and non-vital RAM that holds messages and telemetrj' data. 

1. PROM storage for operating system kernel 

Initial program load will be accomplished from the on-board read only memory. 
This is one of the vital links in the system. If the program in this PROM becomes cor- 
rupted, it may not be possible to successfully restart or reload the satellite system. A high 
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reliability, fuse programmed PROM will be required to ensure that this program does 
not become corrupted. An additional measure of reliability can be added by using two 
separate PRO .Ms as was done on UoSAT-2. L’oSAT-2 had a separate command channel 
to enable the alternate PROM. As previously determined, PANSAT will only have one 
communication link. The switch between PROMs cannot be commanded directly. One 
solution would be to have the PROMs toggle on each reset. If one fails, then two se- 
quential resets would be required to restart on the good PROM. This would be incon- 
venient, but better than having a totally failed system. 

Two alternatives exist for the size of the program loaded into the PRO.M. The 
preferred alternative is to have the entire satellite operating system in the PROM. In this 
case, a reset would completely initialize the satellite and set it up for store and forward 
communications. If sufficient PROM storage is not available, or the store and forward 
software is too complex, the PROM program could just initialize the satellite commu- 
nications link to receive an uploaded program. Typical satellite PROMs var\’ between 
two and eight kilobytes of storage. The L'oSAT-2 used only 512 bytes of PRO.M. This 
loaded a minimal program that enabled the processor to receive the operating program 
over the digital communication link [Ref 3]. The FO-12 was unique in that it contained 
no read only memory’. 

Since the PROM will contain the bootstrap program for the processor system, 
software reliability is a large concern. The software burned into the PROM must remain 
error free. PANSAT will have the capability to be reprogrammed, but this is only pos- 
sible if the communication link is properly initialized on the satellite. 

2. Vital RAM for operating system functions. 

The read-write random access memory (RAM) can be divided into two sections: 

• vital Ri“\.M, in which a bit error would adversely affect system operation, possibly 
requiring resetting the system 

• non- vital RAM, in which a bit error may corrupt a message but does not affect 
system operation. 

A preferred system design would have all RA.M implemented in radiation hardened de- 
vices and would provide error detection and correction. As previously mentioned, radi- 
ation hardened memory devices are much more expensive. Error detection and 
correction requires four additional bits per word for eight bit words, and five additional 
bits for 16 bit words. Additional hardware is required for error correction beyond the 
increase in storage required. While error detection and correction is a desired feature, it 
is not required for the relatively simple, low cost design of PANSAT. Instead, vital 
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memor>' will rely on the immunity of radiation hardened RAM to single event upsets. 
Eight kilobytes of storage will initially be allocated as vital RAM. 

3. Non-vital RAM 

Non-vital Rj-\M will compose the bulk of processor memory. This area will in- 
clude the store and forward messages and telemetry' data. The size of this RAM is limited 
by available power, volume, and addressing capability. Within these bounds, this mem- 
ory should be as large as possible. As an alternative to radiation hardening, this I^.M 
should be sectioned, allowing the processor to disconnect a faulted section of memory 
from the power supply. This will allow latch-up conditions to be reset or permanent 
failures to be isolated to reduce impact on the total system. For maximum reliability, 
the processor initialization sequence could remove power from non-vital memory, then 
power up sections and assign addresses as needed. This would prevent a non-vital Rv\.M 
failure from preventing a successful initialization. 

4. Monitoring 

If sufficient telemetry channels are available, the current to independent non- 
vital memory sections could be monitored. This would provide data on how current draw 
changes in memory devices with long term radiation exposure. In addition, it may pro- 
vide data to analyze failure of a memory section. 

G. WATCHDOG TIMER 

A method was previously developed to reset the processor and exhibit control over 
the transmitter if the processor of IIDLC protocol controller failed. However, if the re- 
ceiver is the failed component, this method will not secure a malfunctioning transmitter. 
As an additional safeguard, a count down timer could be used to monitor processor 
operation. During proper operation, the processor would reset the timer count at regular 
intervals. If the processor exhibited a software failure, potentially placing the processor 
in an infinite loop and leaving the transmitter keyed, this timer would expire. Expiration 
of this timer would cause a software reset of the processor, reinitializing the system and 
securing the transmitter. The periodic timer count reset must not be an interrupt func- 
tion, but a normal function of properly operating software. If it is an interrupt function, 
it will not break the infinite loop condition; the interrupt will return to the infinite loop 
after resetting the watchdog count. 

H. INTERRUPT CAPABILITIES 

Data transfer between the processor and HDLC formatter was previously deter- 
mined to be optimally performed by processor interrupts. The analog to digital converter 
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may also be designed to interrupt the processor when conversion results are available. 
An on-board experiment may be designed to interrupt the processor when service is re- 
quired. A timer may be used to interrupt the processor when the next regular house- 
keeping task must be performed or telemetr>^ data gathered. These imply that the 
processor must have at least five levels of interrupt with appropriate circuitry to receive 
and process interrupts. Typical interrupt controllers provide eight channels, providing 
for flexibility in interrupt design. 

I. INITIAL DESIGN CONCEPT 

The concepts explored in the above sections determine the desired baseline design 
of the PANSAT on-board processor. These functions and interfaces are illustrated in 
Figure 7 on page 29. 
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Figure 7. PANSAT processor initial system concept 
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III. PROCESSOR DESIGN 
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A. PROCESSOR SELECTION 

Current Space Systems Academic Group projects use the NSC-800 as the basis for 
processor systems. The current design has at least four years of operation and testing. 
However, a more powerful system is required to implement the store and forward mes- 
sage system. A previous design was attempted with an 8085. This processor did not have 
high enough throughput for even the simpler requirements of previous experiments. 

The microcontrollers (MC68HC11 and 8096) offer interesting possibilities for space 
based control applications. They contain a processor, RAM, ROM, clock, reset circuit, 
watchdog timer, interrupt circuit, prograinmable timer, serial port, several parallel ports, 
and an A 'D converter, all within a single chip. The disadvantage of using a microcon- 
troller is that on chip memor>’ is limited and addressing memory’ off' chip is clumsy. Ad- 
ditionally, read only memory is implemented in EPROM which is not suitable for higher 
radiation environments experienced in space. Procuring a chip with ROM instead of 
EPROM requires mask charges and large orders; otherwise unit costs are high. This 
eliriinates the microcontrollers from consideration. 

The 8086 and MC68000 are both sophisticated, medium performance micro- 
processors. The advantages of the MC68000 are: 

• the data bus and address lines are not multiplexed (as in the 8086) 

• memory and 1,0 interface is simplified through use of DTACK protocol, 

• the address bus uses 24 bits (versus 20 in the 8086), and 

• peripherals are mapped into memory, simplifying I;0 data transfer. 

The advantages of the 8086 are: 

• a full family of CMOS products exists, including commercial, industrial, high reli- 
ability, and radiation hardened. This allows initial design in low cost components 
with the more expensive components used in the final implementation. 

• A large number of software development tools are available. 

• Software presently exists that implements the store and forw’ard protocol. 

• Other satellites have been constructed based on the 8086, thereby establishing a 
history of reliable space operation. 

Based on the 8086 advantages, an 8086 system will be designed. The specific processor 
targeted is the Harris 80C86RH, a radiation hardened, C.MOS version of the 8086. 
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B. PROCESSOR MODE SELECTION 

The 80CS6RH can operate in either minimum or maximum mode. In maximum 
mode bus control signals are multiplexed on three pins; SO*, SI*, and S2*. (The * is 
used to indicate an active low signal.) These signals are used by the 82C88 bus controller 
to synchronize bus operations and to allow for more than one bus master. Since the 
maximum mode requires an additional chip and since the flexibility of having more than 
one processor access the bus is not required, the minimum mode will be used. Minimum 
mode is selected by tying MX, MX* to Vdd. 

In minimum mode, the 80CS6RH directly generates signals necessary to control read 
or write to memoiy or peripheral devices. These signals are RD*, WR*, and M lO*. 
RD* is active for reading from devices. WR* is active when writing to devices. M, 10* 
is high when accessing memoiy address space and low when accessing 10 (or peripheral) 
address space. The 80C86RH data bus is 16 bits wide, but it can access individual byte 
items. The processor uses AO and BHE* to indicate whether an action affects a byte or 
a whole word. The effect of these signals is shown in Table 6 [Ref. 1 1: p. B-8]. When a 
byte operation is performed, the bus interface unit inside the 80C86RH automatically 
routes the byte from the high or low half of the data bus to the proper internal register. 



Table 6. BYTE SELECTION CONTROL 



BHE* 


AO 


Bytes accessed 


0 


0 


Whole word 


0 


1 


Upper byte to from odd address 


1 


0 


Lower byte to from even address 


I 


1 


None 



In either mode of operation, address and data information are time multiplexed onto 
the same bus. The 80C86RH bus cycle consists of four clock periods. These are labeled 
T1 through T4. (In some cases, wait states are inserted between T3 and T4. These are 
indicated by Tw.) During Tl, the processor provides the selected address on A0-A19. 
During the remaining periods, the processor will read data from or write data to A0-A15 
while A16-A19 provide status and control for maximum mode system. Address and data 
information must be demultiplexed from A0-A19 external to the 80C86RH. In mini- 
mum mode, the processor generates ALE, DEN*, and DT/R* to control demultiplexing. 
Two methods of demultiplexing are available. The first method uses synchronous 
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memon^ devices designed to operate directly with the 80C86RH. These memory devices 
have internal latches to hold the address during decoding and memory access. One such 
device is the Harris 92560 64 kilobyte by 8 bit synchronous R.A.M module. Using 
synchronous modules presents several limitations. A limited selection of devices is 
available. These devices are not pin compatible with standard 28 pin memory devices. 
Inability to acquire the exact device that the system is designed to use may force a re- 
design. These synchronous RAM modules are not typically available in radiation hard- 
ened or high reliability versions. In addition, unless synchronous decoders are used, the 
upper address bits, AO, and BHE* must still be latched externally for chip select decod- 
ing. Most 80C86RH peripheral devices are not synchronous so address bits used by pe- 
ripherals must also be latched. Last, the drive capability of the 80CS6RH outputs is 
limited, so an external bus driver may still be required. With these disadvantages, a 
synchronous system using the multiplexed bus is not the solution for PANSAT. 

The second demultiplexing method uses external latches. These latches are loaded 
with an address during Tl. They then maintain a stable address throughout the entire 
bus cycle. Since PANSAT will be a multiple board system, two additional options exist. 
These are demultiplexing the buses on the main board and distributing demultiplexed 
data, or distributing the multiplexed bus and providing address latches on each board for 
local demultiplexing. Since the circuit boards will be separated by several inches at most, 
and the PANSAT design is to be simple, only one set of address latches will be used and 
the demultiplexed bus distributed to the secondary’ boards. 

The 80C86RH is rated to operate from DC up to five .MHz. (Since the circuit is 
C.MOS and does not use dynamic storage, the clock can be stopped without loss of sta- 
tus. This is different from the initial 8086 which used dynamic storage and had a mini- 
mum clock frequency of two MHz.) At maximum rated frequency the processor requires 
a 33 percent duty cycle clock. The clock must be active (high) for 33 percent of the clock 
period; this is to ensure that the clock inactive time is at least 118.6 nanoseconds. If a 
frequency less than 4.2 MHz is selected, a symmetric clock may be used. In this design, 
a five MHz clock will be assumed. This gives a clock period of 200 nanoseconds and a 
bus cycle time (with no wait states) of 800 nanoseconds. This timing is conservative by 
current device standards and will allow wide flexibility in choosing memory’ and periph- 
eral devices. 
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C. BUS DEMULTIPLEXING 

A typical minimum system, shown in Figure 8 on page 34, uses three 82C82 octal 
latching bus drivers to demultiplex the address bus and two 82C08RH bus transceivers 
to drive the data bus. These circuits are not appropriate for PANSAT. The 82C82 is 
not available in a radiation hardened version. This is solved by substituting three 
54HC573 octal latches in place of the 82C82s. The 54HC573s are functionally identical 
to the 82C82s and are available in high reliability versions. The timing of the 82C08 is 
marginal for the system. System timing using the 82C08 in a synchronous design with 
92560 synchronous RAVI modules is shown in Figure 9 on page 35. The worst case 
timing is shown. DEX’" goes active 110 nanoseconds after the rising edge of T2. This 
activates the 82C08 output which has a 130 nanosecond delay until the output is valid. 
As shown, this will present data to the 80C86RH exactly at the setup time with no 
margin. To use the 82C08 reliably, the system must be slowed. As an alternative to 
slowing the system, the 82C08s can be replaced by 54HC245 transceivers. These are 
functionally identical to the S2C0Ss but have only a 30 nanosecond delay from enable 
to output. 

The data bus transceivers are not required for system bus demultiplexing as this was 
accomplished by the address latches. They serve two other purposes. First, they increase 
the output drive of the S0C86RH and provide isolation of data bus components from 
the processor. Second, they reduce bus contention by isolating the data bus from the 
address bus during T1 while the processor is outputting an address. 

Three 54HC573s are required to latch a 20 bit address plus BHE''’. Latching the 
address is controlled by ALE. The latch outputs are permanently enabled by tying out- 
put enable (OE" ) to ground. The 80C86RH does not provide a signal that could be di- 
rectly used to enable address latch output only when a valid address exists. Therefore, 
the address latch output will be permanently enabled. Permanently enabling these out- 
puts will not cause contention on the demultiplexed address bus as the 80C86RH is the 
only source of an address. 

Two 54HC245s are required to drive a 16 bit data bus. Direction of transfer is con- 
trolled by DT/R*. The output enable (OE*) of the 54HC245s is controlled by DEX’^ 
from the 80C86RH. This signal is active only during T2, T3, and T4, after the address 
output has been latched and the multiplexed system bus is ready for data transfer. Op- 
eration of DT R ". DEX'*, and 54HC245 direction of transfer is shown in Table 7 on 
page 34. 



33 



)N'I 




Figure 8. Minimum mode HS-80C86RH typical configuration: [Ref. 6, p. 4-65J 



Table 7. DT/R* AND DEN* CONTROL OF 54HC245 



DEN* 

(EN*) 


DT/R* 

(A-.E) 


data direction 


54HC245 function 


0 


0 


read data (to processor) 


E to A 


0 


I 


write data (from processor) 


A to E 


1 


X 


none 


high impedance 



The interconnection of the 80C86RH, 54HC245s, and 54HC573s are shown in Fig- 
ure 10 on page 36. (The symbol for pin 1 of the 54HC245 may be confusing as it indi- 
cates -» 5 is an active low signal. In fact, this signal behaves as shown in Table 7 on 
page 34.) In this and all following circuit schematics the following signal names are 
used: 

• ADO through AD 19 for the multiplexed system bus, 

• EDO through ED 15 for the demultiplexed (bulfered) data bus, and 

• EAO through EA19 and EEHE* for the demultiplexed (buffered) address bus. 
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Figure 9. System timing using 82C08 bus tranceivers 
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Figure 10. Pansat processor main board 
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(FROM MODEM 



D. OTHER PROCESSOR CONNECTIONS 



The 80C86RH TEST'" pin operates with the 80C86RH WAIT instruction. A WAIT 
instruction will cause the processor to idle while testing the TEST'" input. When the 
TEST" input goes active, processor activity will resume. This pin could be connected to 
a timer output to allow the processor to run idle cycles for a predetermined time. How- 
ever, this method of synchronization could lead to an infinite loop if the timer was im- 
properly initialized. Synchronization with external devices such as telemetry’ collection 
or an embarked experiment is better accomplished through an interrupt structure. The 
TEST'^ input is connected to ground (permanently active) so a WAIT instruction will 
have no effect. 

The HOLD input allows another processor to access the local bus. When HOLD is 
active, the 80CS6RH will place the system bus and control lines in a high impedance 
state until HOLD goes inactive. This feature is not desired and HOLD is made perma- 
nently inactive by tying to ground. HLDA is an output acknowledging HOLD and has 
no connection. (Figure 10 on page 36 shows HOLD as RQ’''/GT0’=’ and HLDA as 
RQ'*', GTL". These are the maximum mode pin definitions.) 

E. CLOCK GENERATION 

To operate the 80C86RH at the maximum rated speed of five MHz requires an 
assymetric, 33 percent duty cycle clock. This can be generated by the 82C85RH clock 
generator circuit. The S2C85RH requires a frequency source operating at three times the 
desired clock frequency. This can be generated by placing a 15 MHz parallel resonant, 
fundamental mode ciystal across XI and X2 and tying E C* low (to select internal fre- 
quency source). To ensure stable oscillator operation, two capacitors are added such that 
their combined capacitance ( ^ ) matches the load capacitance required for the 

crystal (Ref 6: p. 4-143). The values for these capacitors will be determined when the 
actual crystal is obtained. The required 33 percent duty cycle clock is available on CLK 
and may be connected directly to the 80C86RH CLK input. 

In addition to clock generation, the 82C85RH also provides: 

• power on reset generation using a Schmidt trigger, 

• clock start/stop and slow/fast control, 

• two separate ready and ready qualification inputs, 

• a 50 percent duty cycle clock, and 

• a peripheral clock operating at one sixth the crystal frequency. 
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The start'stop control requires an 82C88 bus controller or discrete circuitry to decode 
the halt command on SO*, SI*, and S2*. In addition, once the clock is stopped an ex- 
ternal event (interrupt) is required to restart the clock. To prevent a HALT command 
from stopping the clock without external means to restart the clock, this start, stop ca- 
pability will not be used in this design. The start command will be permanently enabled 
by tying START to Vdd. 

The Schmidt trigger reset circuit generates the required width reset pulse for the 
system. The minimum high voltage on the reset input is 2.8 volts. An external resistor- 
capacitor (RC) network must be added to keep the 82C85RH reset input below 2.8 volts 
until the power supply stabilizes at five volts, then allow this input to increase. The 
capacitor voltage is given by: 



where V is the power supply voltage and i is time. The value of RC depends on power 
supply characteristics and will be determined when power supply design is complete. A 
communications system reset output will also be connected to the 82C85RH reset input. 
Due to the external pullup resistor, this second input should be connected through an 
open collector output stage. 

Ready generation will be examined with peripheral and memory’ design. The re- 
maining 82C88RH functions will not be used. The 80C85RH connections are shown in 
Figure 10 on page 36. 

F. 80C86RH PERIPHERALS 

Peripheral devices supporting the 80C86RH may be addressed by one of two meth- 
ods. They can be mapped into the 2^® address memory space or into a separate 2‘® ad- 
dress L'O space. The advantage of mapping into the memory space is that all memory 
operations, such as MOV, PUSH, and POP, may be directly applied to peripheral de- 
vices. However, the 80C86RH cannot directly move from one memory’ location to an- 
other. This requires two separate bus operations and two separate instructions. If 
mapped to the I/O space, all transfers must go through register AX or AL using the IN 
or OUT instructions. Since both methods require two instructions and two bus cycles 
to transfer a byte from memory’, the only advantage to mapping peripherals into the 
memory address space is the ability to use any register to temporarily hold the trans- 
ferred byte. If memory mapping is used, some portion of address space is lost. In certain 
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instances, the IX and OUT instructions are faster than memory instructions. For these 
reasons. PAXSAT processor peripherals will be mapped to the 1,0 space. Chip select 
for peripheral devices will be considered after addressing requirements for all peripheral 
devices are examined. 

The peripherals required for the system depend on the functions desired. PAXSAT 
will require the following peripherals: 

• Analog to digital converter, 

• parallel input output ports for device control, 

• interrupt controller (since the 80C86RH will only recognize two levels of interrupt 
without external circuitry), 

• a timer circuit(s) for the watchdog timer, and 

• an HDLC protocol controller. 

The selection and connection of these items is described below. 

1. Analog to digital converter 

The analog to digital converter will receive analog signals through a series of 
multiplexers and provide a digital output to the processor. Typically eight bit accuracy 
would suffice for PAXS.AT purposes. However, the ideal choice for the PAXSAT is the 
Intersil ICL7115. This is available in CMOS and provides 14 bits of accuracy. In addi- 
tion, interface to the 80C86RH is simplified as it will directly map to the 1 O space and 
recognize processor signals for control. WR* will initiate a conversion cycle and RD* 
will allow the processor to read the results. 

The ICL7115 will perform 14 bit conversions in 40 microseconds using a 500 
kHz clock. Rather than add a 500 kHz crystal to the circuit (crystal connections are 
available on the 1CL7115), the system clock is divided below 500 kHz to provide the 
conversion clock. Proper system operation will then rely on only one clock rather than 
two clocks. The 82C85 50 percent duty cycle clock (operating at five MHz) is used to 
clock a 54HC161 binary counter. The QD output then provides a clock that is l;16th 
the input frequency, or 312.5 kHz. This provides a conversion time of 64 microseconds. 
(The 54HC161 connections to implement a divide by 16 counter are shown in 
Figure 10 on page 36.) This 312.5 kHz clock is connected to the OSC2 input of the 
ICL7115. 

The 1CL7115 provides 14 bits of output plus an over-range flag. The output bits 
are connected to BD0-BD13 while the over-range flag is connected to BD14. This allows 
a single word transfer (such as; IX address,AL) to read conversion results. On occasion, 
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the programmer may wish to load only the low or high byte of the conversion. This is 
controlled by the AO and BUS pins of the 1CL7115. These are connected to BAl and 
BA2 to perform this selection. BAO cannot be used for this selection as it indicates 
whether the low or high byte of the data bus is to be read by the 80C86RH processor. 
In the ICL7115, selection of low or high byte routes the selected byte to the low byte 
of the data bus. Therefore AO must be low (0) to read the low byte of the data bus. 
Table 8 summarizes the control of the ICL7115. 



Tables. ICL71 15 CONTROL 



WR- 


RD=" 


BUS 

(BA2) 


AO 

(BAD 


Action 


0 


X 


X 


X 


Initiate conversion 


X 


0 


0 


0 


low byte to BD0-BD7 (A0 = 0) 


X 


0 


0 


1 


high byte to BD0-BD7 (A0 = 0) 


X 


0 


1 


X 


both bytes to BD0-BD14 (AO.BHE ' = 0) 


X 


1 


X 


X 


high impedance output 



The analog signal is input on Vinf Vins provides an output of the voltage 
sensed by the ICL71 15. This can be used to drive an op amp to restore any voltage drop 
in sensing lines. Similar arrangements are possible on the reference voltage and analog 
ground inputs. Due to the small size of PAXSAT, these op amps will probably not be 
necessary and are shown as optional in Figure 1 1 on page 42. When the telemetr\' sys- 
tem design is finalized, the telemetry designer will determine the need for these op amps. 
The VREF input should go to the best regulated high voltage on-board PAXSAT to 
provide a stable reference. (All conversions are referenced as a percentage of this volt- 
age.) 

The analog voltage input to the ICL7115 is selected by two levels of 54HC4051 
analog multiplexers providing 36 telemetry input channels. Up to four additional 
54HC4051S may be added to increase input to 64 channels while maintaining only two 
level multiplexing. The primar\’ 54HC4051 is controlled by four bits of a parallel output 
port, with one bit enabling output and three bits selecting the input channel. The second 
level multiplexers are similarly controlled as a group by the remaining four bits of the 
parallel port. 
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The ICL71 15 indicates conversion is complete by a high level on EOC. This can 
be used to cause an interrupt request for the S0CS6RH to read the conversion value and 
initiate the next conversion. The 1CL7115 and 54HC4051 connections are shown in 
Figure 11 on page 42. Specifications for the 1CL71 15 are found in reference 12. 

2 . Parallel input/output port 

The PANSAT processor requires a parallel output capability to control the 
telemetry multiplexers and other device on, 'off control. The 82C55RH provides three 
bidirectional eight bit ports that can be used for this purpose. Since the 80C55RH is an 
eight bit device, it is connected to only the lower eight bits of the data bus (BD0-BD7). 
The 80C55RH has four internal registers, selected by AO and Al. However, the 
80C55RH AO cannot be connected to BAO. BAO selects the low byte for a transfer, and 
if BAO equaled 1 to control 80C55RH register selection, this would disable transfer from 
the low eight bits of the data bus. Therefore AO is connected to BAl and Al to BA2. 
The operation of these signals is summarized in Table 9. 



Table 9. 80C55RH REGISTER SELECTION 



Al (BA2) 


AO (BAl) 


Register selected 


0 


0 


port A 


0 


1 


port B 


1 


0 


port C 


1 


1 


control word 



RD* is connected to the svstem read signal and \VR* is connected to the svstem 
write signal. These signals determine whether a control or output word is to be written 
to or read from the 82C55RH. The 82C55RH RESET input is connected to the system 
reset signal generated by the 82C85RH. The chip select input will be considered later. 

The 82C55RH has three operating modes with multiple submodes. In the 
PANSAT processor, only simple output is required. This is mode zero. All three ports 
are configured for output by writing 10000000b (128h) to the control word. Port A is 
connected to the multiplexing system for the ICL7115. The control effect of these con- 
nections is summarized in Figure 12 on page 43. 

The parallel port also implements device control through port C. Port C was 
selected for this control since individual bits of port C can be set or reset with a special 
control word. This allows changing status of one device without causing a glitch in the 
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14 BIT A/D CONUERTER 
. AAX02 
ICL7115 



BD14 

BD13 

BD12 

BDll 

BD10 

BD9 

BD8 

BD7 

BD6 

BD5 

BD4 

BD3 

BD2< 

BDl- 

BD0' 



OUR 


UREFF 


D13 


UREFS 


D12 


AGNDF 


Dll 


AGNDS 


D10 


UINF 


D9 


UINS 


D8 




D7 


CAZ 


D6 




D5 




D4 


COMP 


D3 


PROG 


D2 


TEST 


D1 


B17 


D0 


B16 




BIS 


C5 




RD 


DGND 


UR 




A0 


SC 


BUS 


OSCl 


EOC 


0SC2 
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GND 

+5U 

+SV 

NC 

NC 

NC 



—GND 

32 

If NC 
— CLK.3 




STABLE REFERENCE UOLTAGE 



ANALOG GROUND 



ANALOG MUX 
. AAR02 
54HC4051 



TLM15 

TLM14 

TLM13 

TLM12 

TLMll 

TLM10 

TLM9 

TLM8 

PA2 

PAl 

PA0 



1 



PA6 



ANALOG MUX 
. AA502 
54HC4051 



TLM7 

TLM6 

TLM5 

TLM4 

TLM3 

TLM2 

TLMl 

TLM0 

PA2 

PAl 

PA0 



PA6 



1 



ANALOG MUX 
. AAU02 
54HC4051 



Y7 


TLM31-|- 


Y7 


YB 


TLM30-$- 


YB 


YS 




TLM29-^ 

TLM28*^ 

TLM27||- 

TLM26~f- 

TLM2S“^ 

TLM34-i^ 


YS 


Y4 




Y4 


Y3 




Y3 


Y2 




Y2 


Y1 2 


3 


Y1 2 




Y0 




Y0 


A2 




PAl^ 
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A2 
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A1 


A0 




A0 
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Y2 

Y1 2 


3 


Y2 

Y1 2 


Y0 




Y0 
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A1 


A0 

E 
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Figure 11. PANSvVT processor telemetry section 
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PRIMARY 

MULTIPLEXER 

enable 


SECONDARY 

MULTIPLEXERS* 

ENABLE 


PRIMARY 


rWLTIPLEXER 


jCHANNEL 


SECONDARY 


MULTIPLEXERS’ 


CHANNEL 


BIT 7 


BIT 6 


BIT 5 


BIT 4 


BIT 3 
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THIS CONTROL UORD IS WRITTEN TO PORT A TO CONTROL ICL711S MULTIPLEXER INPUTS. 



Figure 12. ICL71 15 input channel selection 

status of anotlier device. This control word is shown in Figure 13 on page 44. Two 
54HC4016 quad bilateral switclies are used to provide eight channels of digital control. 

When the 82C55RH is reset, all ports are set to input mode with input pins 

pulled up to Vdd. To have this condition disable all devices controlled through the 

5411C4016s, the port C outputs are connected to the 54IlC40l6s through inverters. 
Since the 82C55RH outputs are latched internally, an external latch is not required. If 
more than eight channels of control are required, port C could be used to drive two 
541IC259 eight bit addressable latches, each driving two 541IC4016s. This will provide 
sixteen channels of control. As an alternative, port B could also be used to drive two 
54HC4016s. However, port B is not bit addressable and may not provide glitch free 
control. At present, port B is reserved for future use. Figure 14 on page 46 shows the 
82C85ARH connections. 

3. HDLC protocol controller 

The need for an HDLC controller to format the packet conununications was 
analyzed previously. The 8273 HDLC controller can be mapped directly into the 1/0 
space like other peripherals. Like the 82C55RH, the 8273 is an eight bit device. This 
implies the same limitations on using BAO as an address input. 1 he data bus 

connections, RD*, WR*, and RESET connections are similar to the 82C55RH. The 

previous analysis showed that an interrupt driven HDLC controller would be sulllcient 
for the PANSAT processor. The 8273 is therefore connected for interrupt driven control. 
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CONTROL WORD 




Figure 13. Bit set/reset control word format: [Ref. 6, p. 4-120] 

Two of the four DMA controls are still used to control register access. The others 
(TxDRQ and RxDRQ) are unused. The 8273 AO, Al, TxDACK^ and RxDACK* 
< connections are used with RD* and WR* to access the nine internal registers. 
TxDACK* selects the transmit data register; RxDACK* selects the receive data register. 
Since the 8273 is desigred to operate with a DMA controller, TxDACK* and 
RxDACK* do not require CS* to be active to select these registers. Therefore, address 
lines cannot be used to control TxDACK* and RxDACK* as this may result in errone- 
ous data transfers. These two signals will be generated separately by the chip select de- 
coder to prevent inadvertent data transmission or bus contention. 

The remaining 8273 registers are accessed only when CS* is active. These reg- 
isters may be controlled by BA2 and BAl connected to Al and AO respectively. (As 
previously discussed, the system BAO is not used to control register select in eight bit 
peripherals.) The result of these configuration is that the 8273 uses three peripheral chip 
selects. One is used to control TxDACK*, one is used to control RxDACK*, and one 
for the 8273 chip select (and remaining registers). A sununary of these signals is shown 
in Table 10 on page 47. The connection of TxDACK* and RxDACK* will cause the 
registers controlled by these signals to be addressed as separate I/O devices. 

FLAGDET* is connected to the interrupt controller to provide the capability 
for interrupting the processor when the 8273 detects a valid flag. The remaining con- 
nections go to the communication package. The 8273 provides sophisticated modem 
interface and control capability. This capability is detailed in Reference 13 (pp. 8-163 to 
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8-1 87). The connections required and 8273 operating mode desired will be determined 
when the communication package design is finalized. 

The 8273 HDLC controller does present one disadvantage; it is not available in 
a CMOS version (as of Februarv’, 1989). The TTL version consumes one watt of power. 
This would be a significant fraction of the processor power budget. There are several 
solutions to overcome this disadvantage: 

• implement the DLC protocol in software and replace the 8273 with a USART, 

• implement the DLC protocol in discrete CMOS hardware as done in FO-12, 

• use one of the 54HC4016 channels to power down the 8273 when not in use, or 

• use a simpler, byte serial protocol. 

The disadvantage of software implementation of a bit serial protocol was discussed pre- 
viously. Using a protocol other than AX. 25 defeats one of the main purposes of 
PANSAT. This leaves only the second and third options, of which the third is preferred. 
The effect of powering down the 8273 in an active circuit will have to be tested when the 
breadboard design is completed. A discrete HDLC implementation for PANSAT is a 
complex problem, possibly presenting another thesis topic. 

If the 8273 is powered down, a method is needed to signal the 80C86RH when 
to power up and initialize the 8273. The carrier detect line (CD*) from the communi- 
cation package can be used to provide an interrupt to start this sequence. The 8273 
connections are shown in Figure 14 on page 46. 

4. Tinier 

Implementation of the watchdog timer function requires a timer that will inter- 
rupt the processor and cause the processor to reinitialize if this timer is not reset before 
the timer count ends. This function can be accomplished by using a 82C54RH pro- 
grammable interval timer. The 82C54RH provides three timer channels that can be used 
for multiple purposes. The counters have multiple modes (detailed in reference 6, pp. 
4-100 to 4-115) but the only mode needed is mode zero, interrupt on terminal count. The 
timer two output is connected to the non-maskable interrupt (N.MI) of the 82C86RH 
to provide the watchdog timer function. The remaining counters (one and zero) are used 
to provide interrupts for other functions, such as implementing a real time clock. Since 
one possible operating mode is a programmable rate generator, one of these timers could 
be programmed to generate the 500 kHz (or slower) clock for the 1CL7115. This intro- 
duces another possible failure mode for A/D conversion: the 82C54RH must be operat- 
ing and programmed properly for successful conversion. It is preferable to use the 
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Figure 14. HDLC, parallel interface, and device control 
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Table 10. 8273 REGISTER CONTROL 



TxDACK* 


RxDACK'-' 


A1 

(BA2) 


AO 

(BAD 


RD- 


WR- 


Register (action) 


1 


1 


0 


0 


1 


0 


Command 


1 


1 


0 


0 


0 


1 
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1 


1 


0 


1 
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0 


Parameter 


1 


1 


0 


1 


0 
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simpler (hence more reliable) 54HC161 divide by 16 circuit to reduce the five MHz clock 
below 500 kHz. 

The 82C54RH timers are 16 bit timers without prescaling. (The clock frequency 
is not divided before decrementing the count.) If the timers operated at the full five MHz 
system clock frequency, the maximum delay possible would be 13.11 milliseconds. 
However, a 312.5 kHz clock is available from the 54HC161. Using this to drive the 
82C54RH timers allows a maximum delay of 209.7 milliseconds. If the watchdog timer 
were set to interrupt ever}' 0.2 seconds if not properly reset, this would allow 100,000 
processor instructions (assuming 10 clock periods per instruction) between interruptions. 

If required by an on-board experiment, one of the remaining timers could be 
reconfigured as an event counter or programmable pulse generator. This would have 
required breaking the G.ATE and CLK connections, shown in Figure 10 on page 36, and 
reconnecting these as required by the experiment. 

The 82C54RH inputs A1 and AO determine which of the four internal registers 
is selected for reading or writing. As in previous devices, the 82C54RH is an eight bit 
device connected to the lower half of the data bus. Therefore, BAl and BA2 are used to 
control register selection. RD* and WR* control the transfer direction. The effect of 
these signals is shown in Table 1 1 on page 48. 
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Table 11. 82C54RH REGISTER SELECTION 



A1 
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AO 

(BAD 


Register 
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counter 0 


0 
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counter 1 
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0 


counter 2 


1 


1 


control word 



5. Interrupt controller 

Several dilferent levels of interrupt control have been identified. However, the 
80C86RH has only two interrupt inputs, NMI and I NT. NMI is already dedicated to 
the watchdog timer. To manage the remaining interrupts, an 82C59RH interrupt con- 
troller is used. The interrupts are initially prioritized as shown in Table 12 on page 48, 
but may be rotated or masked by the programmer. SP*/EN* is a dual function pin. As 
an input, it designates whether the 82C59RH is a slave or master. It can also be used 
as an output to control data bufl'ers. In this implementation, it is connected to Vdd to 
program the 82C59RH as a master. The programmer must then select the non-buffered 
mode in initialization command word four. Programming details are contained in Ref- 
erence 14, pp. 3-133 to 3-146. The 82C59RH connections are shown in Figure 10 on 
page 36. 



Table 12. 82C59RH INITIAL INTERRUPT PRIORITIES 



Priority 


Number 


Device 


Highest 


0 


unused 




1 


carrier detect (from communications package) 




2 


82C54RH timer zero 




3 


8273 TxINT (transmitter interrupt) 




4 


8273 RxINT (receiver interrupt) 




5 


82C54RH timer one 




6 


ICL7115 EOC (end of A'D conversion) 


Lowest 


7 


8273 Flag detect (FLAGDET*) 
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6. I/O device chip selection 

Five devices and two special commands have been mapped to the PANS AT 
processor 1,0 address space. The highest address bit used by these devices is BA2. This 
leaves BA3 through BA 15 for decoding chip select. Chip selection can be easily per- 
formed by a 54HC128 three to eight line decoder. Address lines BA3 through BA5 are 
used for chip selection. The 54HC138 output is enabled by M/IO* indicating an I O 
space transfer; otherwise the decoder outputs are disabled. Address bits BA6 through 
BA 15 are not used in decoding. This implies that the device selection repeats even.’ 64 
{40h) addresses up to the maximum address of 65535h. (For example, address 0042h is 
the same as 0002h). One 54HC138 output is unused, allowing addition of an another 
peripheral without revising 1 O device chip select decoding. The 1/0 space map is shown 
in Figure 15 on page 50. Recommended TO device addresses and actions are summa- 
rized in Table 13 on page 52. 

7. I/O device timing requirements 

Although most of the peripheral devices selected are designed to work specif- 
ically with the S0C86RH, a timing analysis must be performed to verify that all read and 
write times are satisfied. The 1 O write cycle will be analyzed first. The 80C86RH pro- 
vides a 340 nanosecond (minimum) write pulse. This guarantees at least a 352 
nanosecond data setup time before WR* goes inactive. The peripheral requirements are 
shown in Table 14 on page 50. This shows that no wait states are required to satisfy 
peripheral write timing requirements. The resulting system peripheral write timing is 
shown in Figure 16 on page 51. 

A preliminary analysis of an 80C86RH I/O read cycle shows that 399 
nanoseconds is available for address access, 364 nanoseconds for chip select access, and 
179 nanoseconds read access time. Timing for this cycle is shown in Figure 17 on page 
54. The requirements for the various peripheral devices are shown in Table 15 on page 
53. Several devices will not meet the minimum guaranteed read access time in all cases. 
RD* may go active as early as 10 nanoseconds into T2, but as late as 165 nanoseconds. 
A wait state must be inserted to satisfy worst case timing. 

The required wait state can be generated by adjusting the inputs to the 
82C85RH ready signal generator. The READY input to the 80C86RH must be disabled 
by the end of T2 (8 nanoseconds into T3) to guarantee the insertion of a wait state (Ref. 
1 1 : p. A-23]. Two ready inputs are available to the 82C85RH ready generation circuit. 
In ASYN’C mode, an inactive ready input causes the ready output to go inactive at the 
next downward clock transition. An active ready input is first synchronized to the up- 
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Figure 15. PANSAT I/O space map 



Table 14. PERIPHERAL DEVICE WRITE TIMING REQUIREMENTS 



Device 


Write pulse width 


Data setup to WR* inactive 


1CL7115 


100 nsec 


n a 


8273 


250 nscc 


150 nscc 


8273 

TxDACK 


250 nsec 


150 nsec 


82C54RM 


240 nsec 


225 nsec 


82C55RI1 


100 nsec 


100 nscc 


82C59R11 


1 60 nsec 


160 nsec 
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Figure 16 . Peripheral device nrite timing 
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Table 13. PANSAT I/O DEVICE VALID ADDRESSES 



Device 


Address 


Operand 

size 


Action 


HDLC 

(8273) 


OOh 


byte 


WR- = 0 command register 
RD ' = 0 status register 


02h 


byte 


WR* = 0 parameter register 
RD" = 0 result register 


04h 


byte 


WR- = 0 8273 reset 
RD- = 0 TxlNT result 


06h 


byte 


\VR- = 0 (none) 

RD- = 0 RxlNT result 


28h 


byte 


transmit data register 


30h 


byte 


receive data register 


Parallel 

port 

(8255) 


08h 


byte 


port A (TLM control) 


OAh 


byte 


port B 


OCh 


byte 


port C (device control) 


OEh 


byte 


parallel port control word 


Timer 

(8254) 


lOh 


byte 


counter 0 


12h 


byte 


counter 1 


14h 


byte 


counter 2 (watchdog timer) 


16h 


byte 


timer control word 


A D 

Converter 

(ICL7115) 


18h 


byte 


WR~ = 0 initiate conversion 
RD’" = 0 low byte of result 


lAh 


byte 


RD" = 0 high byte of result 


ICh 


word 


both bytes of result 


Interrupt 

controller 


20h 


byte 


command register 0 


22h 


byte 


command register 1 



ward clock transition, then the READY output goes active at the next downward tran- 
sition, meeting the minimum 80C86RH setup requirements. The ASYNC* input is 
connected to ground to select ASYNC mode. One 82C85RH ready input will be dedi- 
cated to memory operations. For the present, RDYl will be connected to M/IO*. The 
system will normally be ready if memory operations are in progress. (This assumption 
may be changed during memor\' system design.) However, this signal goes inactive 
during I/O operations. This allows the other ready input to control ready generation 
during I'O cycles. The second input, RDY2, is connected to the output of a 54HC00 
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Table 15. PERIPHERAL DEVICE READ TIMING REQUIREMENTS 



Device 


Address access 
time 


Chip enable access 
time 


Read active access 
time 


ICL7115 


200 nsec 


200 nsec 


200 nsec 


8273 


300 nsec 


300 nsec 


300 nsec 


8273 RxDACK 


300 nsec 


n a 


200 nsec 


S2C54RH 


75 nsec* 


0 nsec* 


200 nsec 


S2C55RH 


0 nsec* 


0 nsec* 


200 nsec 


S2C59RH 


210 nsec 


210 nsec 


160 nsec 


•" indicates setup time before RD* goes active 



NAND gate with RD^' and \VR* as inputs. See Figure 10 on page 36 for connections. 
These connections result in a wait state being generated if RD* or WR"^ is not active 
within 45 nanoseconds after the start of T2. (The 82C85RH requires a 55 nanosecond 
setup time. With an 18 nanosecond delay through the 54HC00 and the active clock edge 
occurring at 118.6 nanoseconds, this leaves 45.6 nanoseconds for RD"’ or WR"' to go 
active without generating a wait state.) The resulting access times with the wait state 
added are shown in Figure 18 on page 55. Figure 19 on page 56 shows the resulting 
times if RD* does go active within 45 nanoseconds of the start of T2. 

This design may result in addition of wait states for an TO write which are not 
needed. However, if the decision to insert a wait state is delayed until RD* or WR* go 
active, then the 82C55RH minimum setup times are violated and the required wait state 
may not be generated. The simplicity of this design outweighs this occasional slowing 
of 1 O writes. 

G. MEMORY SYSTEM DESIGN 

.Memory design is affected by the following considerations: 

• The processor must be able to independently address either the lower byte or the 
upper byte, or the entire 16 bit word. 

• The lowest locations in memory' are reserved for the interrupt vector table. 

• Program execution begins at location FFFFOh after reset. 

• Static R.A.M is preferred for reliability reasons and to keep the design simple. 

• Memory circuits may be located on a separate circuit board; connection of the 
memory to the main board must be considered. 
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PANSAT memory is to be divided into three sections: PROM, vital RAM, and bulk 
storage R.AM. To satisfy the above requirements, the PROM should be located at the 
top of memory and contain the restart routine. Likewise, the vital R.-\M should be lo- 
cated at the bottom of memory to hold the interrupt vector table. (Since the watchdog 
timer uses the non-maskable interrupt, this pointer is considered vital.) 

Memorv' boards can be connected to the main board either by the system (multi- 
plexed) data bus, or the separate, demultiplexed address and data buses. Using the sys- 
tem bus requires each memor\’ board to have separate address latches and data 
transceivers. While this prevents failure of one set of address latches from causing com- 
plete system failure, the overall system becomes more complex, therefore more prone to 
failure. Additionally, this increases the required output drive from the 80C86RH. For 
these reasons, using the demultiplexed address and data bus to connect the memory 
boards is preferred. The required signals are BA0-BA19, BD0-BD15, RD*, WR'’, BHE*, 
and M 10-. 

Design is also constrained by available technology and cost. Although one megabit 
static R.“\Ms have just been announced (by at least one vendor), the largest commonly 
used size is 256 kilobit. These are currently available in high reliability versions. Radi- 
ation hardened R.AM is currently more limited, being available in 64 kilobit versions. 
As technology continues to advance, higher density devices will become available in ra- 
diation hardened versions. This presents a problem in memoiy system design. Current 
device availability or cost constraints may not apply as PANSAT approaches launch. 
For this reason, a top down memoiy decoding scheme will be adopted which will readily 
adapt to changing availability of high density, radiation hardened RAMs and PROMs. 
The specific devices that are actually implemented may be changed due to cost, avail- 
ability, or other concerns without requiring a complete redesign. 

PANSAT memory will be divided into 64 kilobyte sections by using the four most 
significant address bits. This is easily accomplished using two 54HC138 three to eight 
line decoders. These decoders are enabled only when M/IO* is high. This is accom- 
plished by connecting M,TO* to a 54HC04 inverter, then to the G2* (active low) enable 
input. (Only one active high enable exists on the 54HC138 and two are needed. Either 
M 10* or BA19 could be inverted. BA19 already has an additional delay through the 
54HC573 addresses latches, therefore inverting M/IO* adds no additional delay.) The 
lowest section will be reserved for vital RAM. The highest section will contain the 
PROM. Remaining sections will contain the bulk R.AM. This approach allows flexibility 
to change devices and the decoding scheme within any section without affecting the 
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overall design. The 64 kilobyte division allows two 32 kilobyte by eight bit (256 kilobit) 
static R.'X.Ms to be used in each section without further decoding. If memories larger 
than 256 kilobit are to be used in the final implementation, the memory' system must be 
redesigned. 

Only devices which are known to be currently available and about which firm data 
is known were considered. There may be a device among the dozens of manufacturers 
that would be better than those chosen but this design will be shown to be sufficient. 

The requirement to address low byte, high byte, or both implies that the memory' 
must be 16 bits wide. Table 6 on page 31 shows how selection is conditioned on AO and 
BHE'“. This implies that BAO will not be used internal to the memory devices for byte 
selection. BAl is the least significant address bit used internal to the memories. The 
distinction between low and high byte need only be made during write cycles. During 
read, the processor only latches the byte required from either the low or high byte of 
AD0-AD15, and internally routes it to the proper register. Write of even addresses must 
be conditioned on AO being low. Write of odd addresses must be conditioned on BHE* 
being low. 

All memory device output enables are controlled by the RD* signal generated by the 
processor. This helps eliminate data bus contention between memory devices on con- 
secutive memory read accesses. 

1. Programmable read only memory’ 

Two 2048 byte C.MOS 6616RH PRO.Ms will be used for permanent program 
storage. These will be located at the top of the memory' address space, occupying ad- 
dresses FFOOOh to FFFFFh. These devices are a radiation hardened version of the 
standard 6616 PROM. This device is also synchronous, but the synchronous capability 
will not be exploited in this design. The device will be connected similar to an asyn- 
chronous memory device; its access times are sufficiently fast that this will not require 
addition of wait states. One device will contain even addresses, the other odd addresses. 
To meet the redundancy discussed earlier, these devices will be duplicated. A circuit us- 
ing one 54HC73 J-K flip flop and two 54HC32 OR gates will be used to select one of 
the PRO.M pairs. The J-K flip flop is connected as a toggle flip flop and uses RESET 
as a clock pulse. The Q and Q* outputs alternately enable the PRO.M sets. This scheme 
relies on the communication system to provide the reset input, otherw’ise another 
method must be provided to select the active PROM. (Selection must not presume that 
the processor is operating properly.) The PROMs are read only, therefore there is no 
need to differentiate between low and high bytes. The top 64 kilobyte section must be 
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divided into four kilobyte subsections for the two 6616RHs. This is accomplished by a 
second 54HC13S which uses BA12-BA15 and the primary 54HC138 output as inputs. 
The circuitry is shown in Figure 20 on page 60. Figure 21 on page 61 shows the result- 
ing system timing. All timing requirements are satisfied with no wait states. 

During system construction and test, the PROMs will be replaced with 
EPROMs. The timing for these devices will need to be verified when they are specified. 

The redundant capability of the PROMs is not matched in the decoding circui- 
try that selects the PROMs. At a slight increase of complexity the decoding circuitry can 
be made redundant. The output of the J-K flip flop can be used as an enable input for 
the first level 54HC138s. The Q output would be connected to one 54HC138 G2B* input 
with the Q* output connected to the other primary 54HC138. Toggling the flip flop 
would alternately select the two decoding circuits. An additional advantage of this circuit 
is that the 18 microsecond delay through the OR gate is eliminated, increasing the read 
cycle margin. This modified circuit is shown in Figure 22 on page 62. The modified 
PRO.M read data timing analysis is shown in Figure 23 on page 63. The simpler, un- 
modified circuit is used in system power analysis. Specifications for the 6616RH are 
found in reference 6. pp. 3-45 to 3-51. Additional information on the radiation tolerance 
of this circuit is found in reference 6, pp. 13-12 to 13-17. 

2. Vital read/iirite memory 

Two eight kilobyte CDM6264CD'3 static RAMs are used for vital RAVI. 
These devices should be procured in the radiation hardened version to meet the reliabil- 
ity requirement for vital RAVI. They are located at the bottom of physical memory from 
address OOOOOh to 03FFFh. The bottom 64 kilobyte section must be subdivided into 16 
kilobyte sections. This is accomplished by using a 54HCI39 two to four line decoder. 
This decoder uses BA14, BA15, and the primary 54HC138 as inputs. The circuitry is 
shown in Figure 20 on page 60. Read data timing is shown in Figure 24 on page 64. 
This shows that critical path timing (chip enable path) is satisfied with a 184 nanosecond 
margin with no wait states. Write data timing is shown in Figure 25 on page 65. Critical 
path timing (data setup time) is satisfied with a 168 nanosecond margin. 

An alternative to the CDM6264CD/3 is the HS-65C162RH static RAM. This 
is a 2048 word device available in a radiation hardened version. A minimum of two de- 
vices would be required to implement a 16 bit memory. The secondary decoder must be 
changed to a 54HC138 to use these smaller memories. Specifications for this device are 
found in Reference 6, pp. 3-29 to 3-32. Device specifications for the CDM6264CD 3 
are found in Reference 15 . 
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Figure 21. PROM read data timing analysis 
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Modified PROM decoding circuit 
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Figure 23. Modified PROM read data timing analysis 
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Figure 24. Vital RAM read data timing analysis 
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DATA LATCHED AT FALLING EDGE OF T3. M/IO* IS ACTIUE DURING ENTIRE CYCLE 
UR» IS INACTIUE DURING ENTIRE CYCLE. 




Figure 25. Vital RAM urite data timing analysis 
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3. Bulk read/\>rite memory 

The bulk R.A.M will be implemented in CDM62256 32 kilobyte static RAMs. 
Sixteen of these devices will provide 512 kilobytes of storage. This will be sufficient for 
the store and forward message bulTer or for holding telemetry' or experiment data. Two 
of these devices will be used in each 64 kilobyte section. The only additional decoding 
required (beyond the top level 54HC138) is selection of even or odd byte (or both) for 
a write cycle. Bulk RAM will occupy memory locations lOOOOh to SFFFFh. To increase 
reliability, this RAM will be divided into four sections, each with a separate 54HC138 
decoder and write conditioning circuit. The circuitry' is shown in Figure 26 on page 67 
and Figure 27 on page 68. The read data timing analysis is shown in Figure 28 on page 

69. This shows that critical path timing requirements are satisfied with a 1 19 nanosecond 
margin and no wait states. The write data timing analysis is shown in Figure 29 on page 

70. This shows that data setup times are satisfied with no wait states. Specifications for 
the CDM62256 are found in reference 16. 

4. Memory summary 

This design provides four kilobytes of PROVI, 16 kilobytes of vital RAM, and 
512 kilobytes of bulk R.'\M. The resulting memory address map is shown in Figure 30 
on page 71. 

H. POWER CONSUMPTION 

The static power consumption for the LSI and MSI circuits is shown in Table 16 
on page 72. This does not include the dynamic power required for operating circuits. The 
address latches and data bus transceivers are in continuous operation, as is the divide 
by 16 circuit and at least one memory decoder. Operating current is not directly avail- 
able from the data book. However, each active output stage can be assumed to source 
or sink 20 microamps. If 50 output stages are assumed to be instantaneously operating, 
this equates to one milliamp. The total current draw for support circuitry is 4.8 
milliamps. Assuming a five volt supply voltage, the power required is 24 milliwatts. 

Static memory power consumption is shown in Table 18 on page 73. Total current 
required is 20.44 milliamps, or 102 milliwatts at five volts. Operating power is spread 
over the entire memory array. The largest operating current is the CD.M62256. Each 
CDM62256 requires 90 milliamps. Assuming word operations, this is 180 milliamps, or 
900 milliwatts. Total current required for memory operations is 200 milliamps, or one 
watt. 
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cure 27. Bulk RAM (Addresses SOOOOli to SFFFFh) 
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Figure 28. Bulk RAM read data timing analysis 
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Figure 29. Bulk RAM nrite data timing analysis 
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The 80C86RH and associated LSI circuit power consumption is shown in Table 17 
on page 72. A total current of 284 milliamps is required, or 1.42 watts at five volts. 

The above power estimates use the military’ temperature rating (-SS'C to 
+ 125 'C). Total current required is estimated at 488 milliamps equating to 2.44 watts 
at five volts. This may be a little high for continuous operation powered only by a small 
solar cell array. If the HDLC power is secured and the processor executes a HALT in- 
struction, waiting for a timer interrupt to restart operation, the required current can be 
reduced by at least 400 milliamps. This will reduce power consumption below 390 milli- 
watts. Securing just the HDLC will reduce the current by 180 milliamps, reducing the 
power consumed to 1.54 watts. 

Table 2 on page 11 shows processor power consumption for the UoSAT-2 and 
FO-12. PANSAT power consumption of 2.54 watts lies between the FO-12 requirement 
of 3.5 watts and the UoSAT-2 usage of one watt. The capability of PANSAT is greater 
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than that of UoSAT-2 but less than that of FO-12. This indicates that power consump- 
tion is appropriate for the capability of the satellite. 



Table 16. LSI AND MSI CIRCUIT STATIC POWER CONSUMPTION 



Device 


Current per device 
ilj. amps) 


Number of devices 


Total current 
(n amps) 


54MC00 


40 


1 


40 


54HC04 


40 


5 


200 


54HC32 


40 


3 


120 


54HC73 


so 


1 


80 


54HC13S 


160 


9 


1440 


54HC139 


160 


1 


160 


54HC161 


160 


1 


160 


54HC245 


160 


2 


320 


54HC573 


160 


3 


480 


54HC4016 


40 


2 


80 


54HC4051 


160 


5 


800 






Total: 


3880 



Table 17. LSI POWER CONSUMPTION 



Device 


Operatine current (milliamps) at 
5 MHz 


80CS6RM 


50 


82C85RH 


30 


S2C54RH 


10 


82C59RM 


5 


S2C55RH 


output drive (up to 3) 


1CL7115 


6 


8273 


180 


Total: 


284 



I. COMMENTS ON THE DESIGN 

To properly survive in the space environment, all circuits must meet military tem- 
perature range specifications. Additionally, they should be procured in hermetically 
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Table 18. MEMORY DEVICE POWER CONSUMPTION 



Device 


Standby 

current 

(milliamps) 


Number of 
devices 


Total standby 

current 

(milliamps) 


Operating 

current 

(milliamps) 


RO.M 

(6616RH) 


0.110 


4 


0.440 


82.5 


\’ital R.AM 
(CDM6264) 


2.0 


2 


4.0 


15 


Bulk R.AM 
(CD.M62256) 


1.0 


16 


16.0 


90 


Total 






20.44 





sealed, side brazed packages. This is in addition to the radiation hardened or high reli- 
ability specifications mentioned above. 

No additional drive has been added to RD", WR*, or M 10. Additional drive on 
these control signals does not appear to be necessar\\ This assumption may need to be 
changed if testing shows additional drive is needed. Sufficient margin exists in all read 
and write timings for the additional delays that would be imposed. 

The design has been kept simple both to keep power consumption low and to reduce 
the probability of failure from complexity. Fairly generous timing margins have been 
enforced to ensure data is transferred reliably. 

The differentiation between vital and non-vital RAM may be fairly artificial, espe- 
cially if all R.-\M is implemented with the same devices. A more elegant solution might 
delete this distinction. Several independently decoded sections of RAM could be pro- 
vided. On reset, the kernel would test all sections and mark sections that fail as una- 
vailable. This would increase the complexity of the kernel that must be present in RO.Vl. 
Additionally, programs uploaded must be dynamically relocatable as any section of 
memory' can be presumed to be unavailable. However, system operation would still be 
affected if low memory containing the interrupt table were unavailable. Even this difft- 
culty could be avoided if some form of dynamic decoding were available. After identify- 
ing usable memory, the processor configures memory so that one of the usable sections 
occupies low memory'. One possible dynamic decoding circuit is shown in Figure 31 on 
page 74. This provides eight possible mappings of eight 64 kilobyte memory sections into 
the low 512 kilobytes of memory. This circuit adds a 24 nanosecond delay to decoding 
(through the EXOR gate). Any single failed section of memory can be moved to the 
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highest address (within the 512 kilobyte space). This and other enhancements to 
PANSAT memory reliability provide areas for further study. 

This design did not explicitly provide a capability to expand into a distributed 
processing network for more complicated systems such as ORION. This capability can 
be added by adding an additional 82C55RH parallel port to the unused section of I/O 
space. This parallel port can be configured for bi-directional, parallel data transfers to 
two other processors. Thus, a ring network of processors could be established. This 
capability is not required for PANSAT and will not be examined further. 
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Figure 31. Dynamic memory decoding circuit and resulting mappings 
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IV. RELIABILITY ANALYSIS 



PAXSAT is a relatively simple satellite. It is not stabilized and has neither a transfer 
rocket motor nor attitude control thrusters. Therefore a processor error cannot cause the 
satellite to de-orbit prematurely or directly endanger human life. It cannot cause an error 
in antenna pointing that would prevent communications with the satellite. A typical 
processor error will cause experiment data to be lost or a message to become garbled. 
The most impact a processor failure could have would be one that caused the transmitter 
to remain continuously keyed. This could disrupt communications on the frequency used 
by the satellite. (This may be self correcting, as continuous transmission may require 
more power than can be supplied by the solar cells.) At worst, complete failure will 
cause a mission failure. Presuming the reset system works through the communications 
link, the processor can be reinitialized after an error causes a program abort. The re- 
quirement is to keep the error rate low enough that useful work can be accomplished 
between system errors. 

Because of the small size and low (relative to typical satellite projects) cost of 
PAXSAT. n-module redundancy and voting techniques are not appropriate. These 
would increase complexity, size, and power consumption beyond the capability of the 
satellite. Additionally, the increased complexity may of itself cause failures. 

Presuming the hardware is operating correctly, the burden for reliable operation falls 
to the software. An initial list of software requirements is listed in the appendix. 

The design of PAXS-AT has centered on several reliability concepts. These are, fault 
avoidance, fault detection, and fault tolerant features. 

A. FAULT AVOIDANCE 

Fault avoidance features minimize the possibility of fault occurrence. PAXSAT has 
two major fault avoidance features. First, system timing has been analyzed to ensure 
that all data transfers will occur reliably. As the components age and are exposed to 
radiation, timing margins may be reduced. Leaving at least 50 nanoseconds margin on 
all critical paths will help minimize errors caused by the effects. Second, the system de- 
sign has been kept simple overall. Xo exotic circuits or methods are used. Ever}’ effort 
has been made to eliminate bus contention. The following items also contribute to fault 
avoidance: 
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• The processor and associated LSI circuitry (except HDLC and A/D converter) are 
available in radiation hardened versions. 

• All SSI and MSI components are available in high-reliability versions. (Radiation 
hardened versions of these circuits are also available if required.) 

• PROM and vital RAM is implemented in radiation hardened devices. 

• Bulk RAM is available in high-reliability versions. 

B. FAULT DETECTION 

The major fault detection feature is the watchdog timer. The watchdog timer is 
implemented to reset the processor if a failure has caused the processor to HALT, enter 
an infinite loop, or otherwise suspend normal program execution. A correctly operating 
processor will reset the watchdog periodically. If the processor does not reset the 
watchdog, the non-maskable interrupt will reinitialize the processor when the timer 
count expires. This feature is dependent on proper software implementation for opera- 
tion. 



C. FAULT TOLERANCE 

Two major features have been included in the design to allow the processor to con- 
tinue operation i^' a circuit or device fails. First, two redundant sections of PROM are 
provided. The reset line toggles PROM selection. Corruption of the program stored in 
one PROM will still allow correct initialization from the alternate PROM on the next 
reset. The second fault tolerant feature is the four redundant memorv' sections. Failure 
of one section will not alTect the remaining sections. In addition, this redundancy could 
be extended to the vital RAM by using an adjustable decoding scheme. 

D. FAILURE MODES 

There are several single point failure items in this system. Failure of any of the fol- 
lowing will cause complete system failure: 

• 80C86RH processor 

• 82C85 clock generator (and clock crv'stal) 

• 82C59RH interrupt controller 

• 541 IC245 data bus transceivers 

• 54HC573 address latches 

• peripheral device chip select (54HC138) 

• 8273 HDLC controller 
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With the exception of the 8273, all these devices are available in radiation-hardened or 
high-reliability versions. The 80CS6RH exhibits a failure rate of 0.00383 percent per 
thousand hours [Ref 6: p. 9-5). (This and all following rates are at +55°C.) The re- 
maining 54HC type circuits exhibit a failure rate of 0.0004 percent per thousand hours 
[Ref 15: p. 70]. (These figures are for the CD54HC version.) Failure rates for the 8273 
are not specified in Reference 13. However, this circuit approaches the 80C86 in com- 
plexity. The standard (not radiation hardened) version of the 80C86 exhibits a failure 
rate of 0.025 percent per thousand hours. If the 8273 failure rate were five times worse 
than the 80C86, this would equate to 0.125 percent failures per thousand hours. During 
the 13,100 hour mission of PAXSAT, this would be a 1.637 percent probability of fail- 
ure. (A factor of five was used to account for the increased stress of orbital environ- 
ment.) The 8273 is then the single item most likely to cause mission failure. Although 
an extensive fault tree analysis was not conducted, a first order estimate based on the 
8273 reliability indicates that the design will have approximately 98 percent probability 
of completing the required lifetime. 

Several other devices could cause partial mission failure if they malfunction. These 

are: 

• 82C54 timer 

• 54HC161 divide by 16 circuit 

• ICL7115 A D converter 

• 82C55RH parallel port 

Failure of these devices will not prevent communication with the satellite or can be 
worked around to restore the function. For example, failure of the ICL7115 A 'D con- 
verter will not directly preclude communication with the satellite, thereby causing 
mission failure. (There may be an indirectly cause, such as this failure causing the power 
monitoring circuit to incorrectly charge the batteries.) The 54HC161 will impact both 
the ICL7115 and the timer if it fails. The 54HC161 may therefore be a candidate for 
duplication. 

Within the allowable complexity, cost, and power budget, the processor design pre- 
sented is sufficiently reliable. Verification of reliable design depends upon actual opera- 
tion. Increasing HDLC reliability to increase overall design reliability is an area for 
further study. 
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V. CONCLUSIONS AND RECOMMENDATIONS 



The PANSAT definition depends on a ground station that can communicate in the 
AX. 25 format. At present, NPS does not have such a communication capability. Ground 
station development and testing need not wait on PANSAT. The ground station should 
be up and operating with current amateur satellites, such as the FO-12, to provide a 
proven ground station before launch of PANSAT. Therefore, the construction of an 
amateur satellite ground station that communicates in the AX. 25 format should be 
undertaken. 

.Vlaintaining acceptable throughput on the store and forward link requires a low bit 
error rate. PANSAT is unstabilized and therefore must use omni-directional receive and 
transmit antennas. PANSAT also has only relatively low power available from the solar 
cell array. Both of these limitations will have a negative impact on the communications 
power budget, and therefore, on the bit error rate. The communications package must 
be carefully designed to maintain acceptable bit error rates under these constraints. 

The functions of PANSAT have been examined and computing requirements for 
these functions determined. A design has been specified that meets these requirements. 
This design included: 

• Four kilobytes of radiation hardened PRO.M, 

• 16 kilobytes of radiation hardened, vital RA.M, 

• 512 kilobytes of high reliability, non-vital RAM, divided into four independent 
sections, 

• seven analog control channels (expandable to 15) for power system and experiment 
control, 

• 36 telemetrx' input channels (expandable to 64) with a 14 bit A/D converter for 
telemetry collection, 

• a hardware HDLC protocol implementation for the communication system, and 

• expansion capability to meet future ORION distributed processing needs. 

Although every effort has been made to ensure this design is correct, it is in essence a 
paper design and as such is subject to limitations. Implementation of the design and 
proving its effectiveness remain as follow-on thesis topics. Due to unknown specifics 
about other satellite subsystems, several items have been incompletely specified. These 
are; 
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• Reset interface to communications system. 

• HDLC interface to communications system. 

• RC value for Schmidt trigger reset input (depends on power system specifics). 

• Interface to get-away special canister while on board the shuttle. 

• 15 MHz crystal load capacitance (depends on specific crystal). 

• Power and experiment control. 

• Telemetry specifics (including whether the A/D precision desired will require op- 
amps to maintain input signal levels). 

While many questions remain to be answered, it is hoped that this first design attempt 
on PAXSAT will serve as a launching point for the additional work required to bring 
up PAXSAT as a viable system. 
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APPENDIX SOFTWARE REQUIREMENTS 

This is a partial list of requirements placed on the software by the particular hard- 
ware configuration. There are two possible implementations for loading the software. 
The kernel may be completely contained in the PROM. Alternatively, only a loader is 
contained in the PROM. This loader will perform the initial configuration on reset, then 
prepare the processor to receive the kernel via the communications link. This is shown 
below as loader initialization and system initialization. If the entire program can be held 
in PROM, these steps should be combined. 

A. LOADER INITIALIZATION 

A jump to the initialization service routine must be located at address FFFFOh 
(within the PROM). This loader routine must: 

• Configure the 80C55RH for mode 0 output and set initial device status through 
port C. 

• Set the 8273 (HDLC) operating mode. 

• Set the 80C59RH (interrupt controller) operating mode and initialize interrupt 
numbers for CD‘‘y RxINT, and TxINT. 

• Set interrupt vectors for CD*, RxINT, and TxINT in the interrupt vector table. 

The initialization routine will then wait for the store and forward program to be up- 
loaded. A variation would not initially power up the 8273, but use the CD* interrupt as 
a signal to activate and program the 8273, then receive the program. In addition, security 
is required to ensure that only an authorized ground station can upload the initial pro- 
gram. 

B. KERNEL INITIALIZATION 

The kernel must perform the following initializations when it is uploaded: 

• Store interrupt vectors for NMI (watchdog) and seven 82C59RH interrupts. 

• Set 82C59RH operating mode, initialize interrupt vector numbers, and unmask re- 
quired interrupts. 

• Set watchdog timer mode and start timer. 

The kernel may then begin normal operations. 



80 



C. REAL TIME KERNEL 



The real time kernel performs the following functions: 

• power management 

• manage the store and forward message system, including scheduling transmissions 
and managing the message buffer. 

• schedule telemetr\’ collection 

• routinely reset the watchdog timer (this must not occur inside an interrupt routine 
or it will not catch system malfunctions) 

• provide security for commands so only authorized ground stations can execute 
commands or upload revised programming 

• receive and execute commands 
D. INTERRUPTS 

Several interrupts are assigned to specific events. The two 82C54RH timer interrupts 
may be used by the programmer to schedule events. Dedicated interrupts are; 

• TxlNT: provide next byte of transmit data to the 8273 

• RxIXT: read next byte of received data from 8273 

• EOC: read conversion result from ICL7115 

• CD: configure 8273 to receive data (This interrupt should be masked if the 8273 
already has power and is configured for operation.) 

The 8273 FLAGDET* interrupt may be used as needed by the software designer. 
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